[ duh, hit send by mistake, message continues... ]
Chris Kuklewicz wrote:
> forkInheritIO :: IO () -> IO ThreadId -- inherits parent's
> block or unblock status
>
> forkBlockedIO :: IO () -> IO ThreadId -- starts the action in
> "block" mode. Must manually "unblock"
>
Either of these is certain
Chris Kuklewicz wrote:
> forkInheritIO :: IO () -> IO ThreadId -- inherits parent's
> block or unblock status
>
> forkBlockedIO :: IO () -> IO ThreadId -- starts the action in
> "block" mode. Must manually "unblock"
>
Either of these is certainly possible, and I agree that forkBlockedIO is more
Hi,
Thanks for the reply. I have my own proposal below:
Simon Marlow wrote:
> Chris Kuklewicz wrote:
>> In response to question by Cat Dancer <[EMAIL PROTECTED]> I wrote a few
>> tests of
>> sending asynchronous signal to a thread using GHC 6.6
>>
>> The goal was to run a child thread via fork
Chris Kuklewicz wrote:
In response to question by Cat Dancer <[EMAIL PROTECTED]> I wrote a few tests of
sending asynchronous signal to a thread using GHC 6.6
The goal was to run a child thread via forkIO and use handle or finally to
respond
to the thread's demise.
Unfortunately, it seems that
