Tim Bunce <[EMAIL PROTECTED]> writes: >On Mon, May 13, 2002 at 01:56:56PM +0100, Nick Ing-Simmons wrote: >> Arthur Bergman <[EMAIL PROTECTED]> writes: >> >On torsdag, maj 9, 2002, at 03:16 , Nick Ing-Simmons wrote: >> > >> >> If you want same kind of abstraction for lighter-weight non-recursive >> >> MUTEX stuff now would be a good time to make the case. >> >> >> > >> >There already is that kind of abstraction >> > >> >MUTEX_INIT MUTEX_LOCK..... all same as 5005 threads. >> >> I meant a run-time switchable abscraction like SvLOCK which >> ALWAYS does CALL_FPTR(PL_lockhook)(aTHX_ sv) >> >> And something populates the variable at runtime. >> >> Likewise we could have Perl_MUTEX_LOCK() always >> CALL_FPTR(PL_mutexlock)(aTHX_ mutex) >> >> and have a dummy function for non-threads case. >> +ve - This makes XS code binary compatible between threads/non-threads. > >Is that relevant given that threads vs non-threads have different arch names >and so extensions install into different directories?
Probably not. But then that would be unecessary if they _were_ binary compatible ;-) -- Nick Ing-Simmons http://www.ni-s.u-net.com/
