On 06 April 2006 23:20, John Meacham wrote:

...

I'm not proposing that we ignore signals, just that we should clearly delimit the platform-specific bits, perhaps by putting signal support into an addendum.

yeah, I was thinking a separate environment addendum should be in the report, which takes behavior that is undefined in the language standard, and defines it for various platforms. it wouldn't extend the functionality or scope of the standard, just define what couldn't be defined in the standard.

like the standard might say "the set of signals is undefined" while the UNIX addendum will say "the set of signals will include at least SIGINT,SIGHUP,etc..."

There's the question of whether ^C should look the same on both Windows and Unix. Windows doesn't have signals as such, but some things like ^C can be made to look like signals. We might consider specifying as part of the portable part of the API that there is at least an "interrupt" signal that corresponds to a user interrupt, and in the platform-specific part of the documentation we say what it actually maps to on each platform (SIGINT on Unix, CTRL_BREAK_EVENT on Windows, etc.).

...

GHC has no support for these right now. They're pretty tricky to handle, because the OS thread that caused the signal to be raised is stopped at some arbitrary instruction, and it would require some serious acrobatics to munge that OS thread into a state where it is possible to raise the (Haskell) exception. I do vaguely recall that people have achieved this in the past, in order to use page faults for write barriers, that sort of thing.

how does ghc handle things like divide by zero then?

By checking before trying to divide :-)

...

...

signal an asynchronous exceptional event - the user should be able to choose the threads on which they wish to catch these, those that need to clean up after themselves.

inform the app of an event it might want to take note of - these should run on their own thread, concurrently to all other threads

GHC directly support the latter version, and you can implement the former with a little extra code and a global variable. I think it would be nice to do as you suggest and provide a way to have the async signals turn directly into exceptions.

One problem, though, is that because we can't interrupt a foreign call with an async exception, ^C can be rather unresponsive. Perhaps I should look into this and see whether it would be possible in GHC for a concurrent foreign call to be interruptible; it would involve terminating the foreign call somehow (pthread_cancel?) before raising the exception. We can't do this in a bound thread, however.

You should be able to handle the SIGINT imediatly no matter whether foregin code is running if your handler is in its own thread right?

Yes, but if the signal handler wants to send an exception to the main thread, as it often does, and the main thread is in a foreign call, ^C appears to not do anything.

just have the C signal handler write a byte to a pipe, your haskell signal handler thread is in a

repeatM $ do readExactlyOneByte signalHandler

loop.

Yes, this is exactly what GHC does.

= minimal proposal =

I think a good minimal solution will be the following, it neatly avoids turning signals into exceptions, which may be problematic, but provides for the common cases of signal usages while being compatible with both cooperative and SMP systems.

== catching signals ==

implementations provide a way of catching signals such that the handler runs as if in its own thread. something like the following

data SigInfo = ... data HandlerType = SigOneShot | SigReset | SigIdempotent

data SigAction = SigAction { signalType :: HandlerType, signalAction :: SigInfo -> IO () } | SigDefault | SigIgnore | SigExit (SigInfo -> ExitStatus)

installHandler :: Signal -> SigAction -> IO SigAction installHandler = ...

the action runs in its own thread.

Yes, looks quite reasonable.

== on exit ==

I'll address this in a separate thread. Cheers, Simon