A while ago, Joshua N Pritikin <joshua.pritikin@db.com> wrote: >On Tue, Nov 16, 1999 at 09:33:54AM -0500, dan@sidhe.org wrote: >> The following patch provides a new macro, SvLOCK, which lets XS code snag a >> perl-level lock on an arbitrary SV *. > >If you publish a macro like this for SvLOCK then you prohibit mixing in >FAKE_THREADS or continuations. Granted, the Perl_call_* API already >complicates things but do we want to expand on this same messy design? >State should not be kept on the C stack lightly. I think a better >solution is to allow a varient of XSUBs that work more like opcodes. Huh? No it doesn't, unless I'm really confused here. With this, to lock a scalar from within XS code means doing: SvLOCK(foo); and nothing more. How does that prohibit mixing in fake threads? (Which don't work yet anyway) The current definition of it may be problematic for fake threads, but that's why it's hidden inside a macro anyway. If/when fake threads work, then we can patch it up, along with what's probably a lot of other stuff. Dan ----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk