[Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Keean Schupke]

But does it matter... If the select says the read will block you schedule
another haskell thread, if select says the read will not block, you do the
read. I don't see the problem... (Okay, I can see that if select lies, 
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data ready)...

So I guess technically other Haskell threads cannot be scheduled during
the read, but as read returns immediately they don't need to...

It seems to me this is why calling read sequentially and with 'unsafe' is
faster than calling it with 'safe' and allowing haskell-thread-scheduling to
occur during the read syscall.

    Is that about right?

    Keean.

Simon Marlow wrote:

>A safe call must 
>
>  - save its state on the Haskell stack
>  - save its thread state object on a queue, so GC can find it
>  - tidy up the stack so GC can take place
>  - release the RTS lock
>  - possibly start a new OS thread if the pool is empty
>
>of these, releasing the RTS lock is probably the most expensive.  Also,
>if another OS thread gets scheduled before the call returns, we have an
>expensive context switch on return.
>
>In contrast, an unsafe call is just an inline C call.
>
>Cheers,
>	Simon
>  
>