Odd behavior of ncurses with -threaded

Simon Marlow marlowsd at gmail.com
Mon Nov 15 04:46:04 EST 2010


On 12/11/2010 17:25, Donn Cave wrote:
> Quoth Simon Marlow<marlowsd at gmail.com>,
> ...
>> Is there anything that we could do in GHC to improve the situation?  I
>> suppose we could have a dedicated OS thread who's job it was to sit
>> around and run the signal handler every Nth of a second.
>
> Since the -threaded RTS automatically spawns a couple of extra
> OS threads anyway, what's one more?

I don't know - maybe it wouldn't be a problem.  But we'd have to measure 
things to make sure the extra thread wasn't impacting performance 
somehow (e.g. by confusing the OS scheduler).

> Quoth Brian Sullivan<bos at serpentine.com>,
>
>> or masking out RTS signals before calling potentially
>> blocking foreign code (which is all my hack does)
>
> And unmasking on re-entry via callback, I suppose.

Right - making a system call for every safe foreign call and 
return/callback probalby would make a difference.

>> It's clear that a large number of C programmers know nothing
>> about restarting system calls, and authors writing FFI code
>> typically can't do anything about that except make sure those
>> system calls don't get interrupted in the first place.
>
> Note that one of the reported victims was "cabal", where I think
> it was a getContents that aborted with EINTR, on OpenSolaris.
> I have no idea what was going on there.

Yes, we still don't know what the problem is there.

Cheers,
	Simon



 > Nor do I have any idea
> why my platform libraries are vulnerable to this signal - maybe
> it's just the usual system call, but I'm not on UNIX.  In the
> present case, ncurses is probably as old as some of the parties
> to this discussion, and you'd have to wonder if after all this
> time it doesn't restart its select() on EINTR, if it isn't because
> that's actually how they want it to work!  I'm not going to defend
> that proposition, but you're right, very low odds that the external
> world will be fixed to support timer signals.
>
> The SIGVTALRM fix solves the problem of an application that
> uses SIGALRM in its own timer.
>
> 	Donn Cave, donn at avvanta.com



More information about the Glasgow-haskell-users mailing list