OHHHHHHHHHHHHHHHH, okay, that makes a LOT more sense! I had thought that "blocking" meant that *all* of the *OS* threads were halted before making the call, but if "blocking" really just means that the calling *OS* thread can't do any other work until the call returns (hence blocking the other *IO* threads mapped to that OS thread) then it all makes sense to me. :-)
Cheers, Greg On 08/03/10 15:49, Gábor Lehel wrote: > As far as I know, it works like this: > > "unsafe" calls are just executed directly, like any other C function > call; as a result, any lightweight haskell threads which were mapped > onto the OS thread in which the call is made are blocked for the > duration of the call; hence why it's a good idea that these calls > should be short ones. So the blocking is not by intent, but -is- a > direct consequence (of how unsafe calls are made and how GHC's > threading system works). Other OS threads and the haskell threads > mapped to them are not blocked, afaik. > > "safe" calls spawn a new OS thread (maybe reuse an existing one if > available?), move the haskell threads over, (do various other > housekeeping?), and then make the call. > > On Wed, Aug 4, 2010 at 12:41 AM, Gregory Crosswhite > <gcr...@phys.washington.edu> wrote: >> On 08/03/10 15:33, Evan Laforge wrote: >>>>> Just think of "unsafe" in relation to "unsafeIndex" or something. >>>>> It's faster, but you have to be sure the index is in bounds. >>>> Yes, but the whole reason to use "unsafe" is to get higher performance >>>> at the cost of safety. If the result of calling an "unsafe" foreign >>>> function is that you *lose* performance because the other threads have >>>> to be halted first, then this seems to defeat the whole point of marking >>>> a call as "unsafe" in the first place. >>> That's why the function has to return soon and shouldn't do a lot of work. >> But again, then what is the point of marking it "unsafe" if it means >> that you have to pay a hefty cost of waiting for all the other threads >> to halt? Is the cost of halting all of the other threads really less >> than the cost of setting up for a "safe" call? Maybe it is, and that is >> what I am missing here. If it is not, though, then it seems to me that >> marking a call as "unsafe" will *never* gain you performance in a >> multi-threaded environment, so that there is never any point in using it >> in such an environment. (Though, of course, it could gain you >> performance in a single-threaded environment.) >> >> Cheers, >> Greg >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
