RE: Calling an external command from a Haskell program
In local.libraries, you wrote:
The sticking point is that GHC needs a thread-safe wait() implementation, which means some hacking in the scheduler (there isn't even a good way to do this portably, because select() doesn't let you wait for process termination).
*mumbl* libevent *mumbl*
I checked libevent, and it doesn't support wait() events. It would be great if it did... Cheers, Simon
On Wed, Oct 22, 2003 at 09:24:28AM +0100, Simon Marlow wrote:
In local.libraries, you wrote:
The sticking point is that GHC needs a thread-safe wait() implementation, which means some hacking in the scheduler (there isn't even a good way to do this portably, because select() doesn't let you wait for process termination).
*mumbl* libevent *mumbl*
I checked libevent, and it doesn't support wait() events. It would be great if it did...
You can catch sigCHLD in the main event-loop and then invoke wait(). [This could even be possible in the current RTS by applying another incarnation of Wolfgang's pipe-hack] -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME
Volker Stolz wrote:
On Wed, Oct 22, 2003 at 09:24:28AM +0100, Simon Marlow wrote:
In local.libraries, you wrote:
The sticking point is that GHC needs a thread-safe wait() implementation, which means some hacking in the scheduler (there isn't even a good way to do this portably, because select() doesn't let you wait for process termination).
*mumbl* libevent *mumbl*
I checked libevent, and it doesn't support wait() events. It would be great if it did...
You can catch sigCHLD in the main event-loop and then invoke wait(). [This could even be possible in the current RTS by applying another incarnation of Wolfgang's pipe-hack]
Why another incarnation? The "first incarnation" should do the job, too. What's wrong with just safe-foreign-calling wait and relying on the threaded RTS to do the job? Cheers, Wolfgang
participants (3)
-
Simon Marlow -
Volker Stolz -
Wolfgang Thaller