>>>>> "EM" == Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
EM> At 12:15 -0500 1/3/04, Uri Guttman wrote: >> >>>>> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes: LT> These are platform specific details. We will use whatever the LT> platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT> The LOCK() can be any atomic operation and doesn't need to call the LT> kernel, if the lock is aquired. >> if it doesn't call the kernel, how can a thread be blocked? EM> Think out of the box! EM> Threads can be blocked in many ways. My forks.pm module uses sockets EM> to block threads ;-). i used that design as well. a farm of worker threads blocked on a pipe (socketpair) to the same process. the main event loop handled the other side. worked very well. EM> It sucks performance wise, but it beats the current perl ithreads EM> implementation on many platforms in many situations. i can believe that. EM> Therefore my motto: whatever works, works. but i discussed that solution with dan and he shot it down for speed reasons IIRC. i still think it is an interesting solution. it could also be used for the main event queue and/or loop as i mention above. we are assuming some form of sockets on all platforms IIRC, so we can use socketpair for that. i even use socketpair on win32 to test a (pseudo)fork thing for file::slurp. >> ...you can't >> have user level locks without spinning. at some point (even with fibres) >> you need to make a kernel call so other threads can run. EM> Possibly. I don't know enough of the specifics whether this is EM> true or not. i looked at the docs for fibres and they say you do a manual reschedule by selecting the fibre to run next or i think a yield. but something has to go to the kernel since even fibres are kernel thingys. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
