Signal handling still buggy
It seems that in 4.08 4.08.1 signal handling still seems to be flawed: I have a program with several concurrent threads, one which waits for keyboard-input, one which handles a dictionary of some data. I install a signalHandler for USR1 which just writes an item to a channel attached to the dictionary process which will happily do whatever I want it to. However, after repeatingly sending this signal, the I/O-loop in the other thread doing the getLine will choke with: Error: failed Action: hGetChar Reason: (error code: 0) Regards, Volker -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
uncertanty about instruction in installation instructions for WinNT
Hallo everybody! I just wanted to setup a new System with ghc-4.08.1 und tried to make everything as mentioned in the "installation instructions". But because I installed cygwin1_1 in root (as suggested) I have to overwrite /bin/sh with /bin/bash and am not sure if I should really do that. And because the PATH variable is still for cygwinb20 I am not sure wich of the variables still have to be set. PATH?-(yes to "/bin/"?); SHELL?-(yes to "/bin/bash.exe"?); MAKE_MODE? (No?); TEMPDIR? So what is to do? Will someone change the "installation instructions"? Thanks, Andreas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Signal handling still buggy
On Mon, Oct 09, 2000 at 01:42:45PM +0200, Volker Stolz wrote: It seems that in 4.08 4.08.1 signal handling still seems to be flawed: I forgot to mention that this only happens when using job-control: 1) start the program 2) use Ctrl-Z to suspend 3) kill -USR1 4) fg to resume, sigUSR1-handler is invoked, the programm still works(!) 5) sending another USR1 -- no matter if suspending or using another shell to issue the kill ! -- will yield the hGetChar-error. Conclusion: This only seems to happen when the program is suspended and receives a signal (it seems any signal will do, I tried sigPIPE, too, in step #3, for which I installed an ignore-handler). On receiving the 2nd signal regardless of being still suspended or not the hGetChar fails. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Signal handling still buggy
On Mon, Oct 09, 2000 at 01:42:45PM +0200, Volker Stolz wrote: It seems that in 4.08 4.08.1 signal handling still seems to be flawed: I forgot to mention that this only happens when using job-control: 1) start the program 2) use Ctrl-Z to suspend 3) kill -USR1 4) fg to resume, sigUSR1-handler is invoked, the programm still works(!) 5) sending another USR1 -- no matter if suspending or using another shell to issue the kill ! -- will yield the hGetChar-error. Conclusion: This only seems to happen when the program is suspended and receives a signal (it seems any signal will do, I tried sigPIPE, too, in step #3, for which I installed an ignore-handler). On receiving the 2nd signal regardless of being still suspended or not the hGetChar fails. Ok. Is it possible to cut down the example to maybe 2 concurrent threads, so we could try to fix the problem here? There aren't any obvious bugs in the signal handling code (at least, not obvious to me :). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
