On Mon, Aug 18, 2008 at 4:13 PM, Simon Marlow <[EMAIL PROTECTED]> wrote: > Dmitry Kurochkin wrote: >> >> On Thu, Aug 14, 2008 at 4:43 AM, Gwern Branwen <[EMAIL PROTECTED]> wrote: >>> >>> Actually, while we're on the topic: why does URL.hs now use forkOS? Darcs >>> uses forkIO, usually, which is the standard Haskell practice. It can't be >>> for performance: I replaced forkOS with forkIO and tested it with 4 darcs >>> gets of the Tahoe repo, and they all clocked in at 24-27 minutes (the same >>> as with forkOS). >> >> That is because we do foreign calls that block. AFAIK if we use >> unbound threads (forkIO) all haskell threads are halt during blocking >> syscalls from foreign functions. And that is not what we want. > > This is a common misconception: forkIO vs. forkOS makes no difference with > respect to blocking. forkOS is only necessary if you need to call a C > library that makes use of thread-local state, otherwise it just uses extra > resources and will slow things down: context-switching between a forkOS > thread and another thread constitutes a full OS-thread context switch, which > is much much slower than switching between forkIO threads. > > People don't seem to believe me when I say this. In retrospect we shoulnd't > have called it forkOS, we should have called it > forkReallyExpensiveOnlyNecessaryForCallingOpenGL_IO.
I do believe you :) I will submit a patch to change forkOS to forkIO. What confused me was this paragraph from forkOS doc: ... Just to clarify, forkOS is only necessary if you need to associate a Haskell thread with a particular OS thread. It is not necessary if you only need to make non-blocking foreign calls (see Control.Concurrent#osthreads). ... "non-blocking foreign calls" - so I thought that for blocking foreign calls forkIO is not enough. Regards, Dmitry > > Cheers, > Simon > _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
