Attached patch is a hacky workaround for the fact that match results are stored in the regexp structure. This was not a problem before qr// because a match could only be used in a single context. However with qr// this is not true. Its possible for a single qr// to be PL_curpm in two seperate scopes with different match results simultaneously, which the current design simply doesnt allow. It also fixes a problem with PL_curpm not being set properly before executing code inside of a (?{}) and (??{}) construct. (This is a recent issue related to the derecursivization of the regex engine.) The solution is that when using a qr// a lightweight copy of the regexp struct is made, and then the matching is done using that. See Perl_reg_temp_copy() for details of the lightweight copy procedure. One reprecussion of this patch is that its no longer possible to get access to the match results in a qr// because the qr// never gets match results as its just a template for the lightweight copy. Long term this all needs to be restructured so that match results data is stored in a different structure which contains a pointer to the regexp that generated it. The instead of taking a copy of the regexp structure we would just create a new regexp result object. Anyway, for now this should do, if we want the more indepth solution ill have to find some time to do it and we will need a fair amount of time to test it, as it will be a very intrusive patch. Patch requires a make regen after application. This will probably break some of the work done by Avar and Audreyt in terms of new engines, as will the proper solution later on. Sigh. But i cant see any way around that, and fixing this properly for 5.10 would be a big deal and delay things quite a bit. End result of this however is that /.../o will become faster to use than /$qr/ in the future, although only moderately so. Not that much data needs to be copied. Cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Next