Proposal: new signal-handling API

[Johan Tibell]

On Fri, Jul 18, 2008 at 5:45 PM, John Goerzen <jgoerzen at complete.org> wrote:
> Duncan Coutts wrote:
>> The main question is if it's too simple. Can people who know about and
>> use signals take a look and see if it covers everything? I'm cc'ing a
>> couple more people who know about and use signals.
>
> 1) Instead of deprecating the low-level API, I would prefer to have it still
> available -- ideally with the new API implemented in terms of it.  I can see
> cases where I really want to make the handler be what I say, not anything
> else.  For instance, say some library was catching SIGABRT for its own
> purposes, but in a certain section of code, I really want SIGABRT to be
> handled in a certain way.  Using the old API, I could save off the old
> handler, install a new handler that does what I want, and restore the old
> one later (assuming I didn't dump core).
>
> [snip]
>
> Thanks for your work on this.  These are probably not popular cases.  On the
> other hand, I have tended to run into limitations in System.Posix in the
> past in areas that weren't anticipated to be popular cases ;-)

I think John raises a very important point. This is something I've
been thinking about since the discussion on the System.Process
overhaul. It's my firm belief that when wrapping a low-level OS
library it's important to provide as much of its functionality as
possible even if that means that the resulting API is quite low-level.
You can of course add some convenience functions on top of the
low-level interface for the more common cases.

In general, it's also important to export (maybe in a .Internal
module) the low-level data types (e.g. file descriptors in the case of
a file API) so that someone else can write an API using the FFI that
integrates with yours. If you provide e.g. a completely abstract
Socket type that wraps the `int' the OS uses to represent the socket
then it's not possible to extend the API from another package.

If you only add the high level functionality that cover say 95% of the
use cases then larger programs will inevitably run into cases when the
current API simply don't support the functionality that you need and
they will have to use resort to using the FFI. This is quite
unsatisfactory as wrapping an OS function so it works on different
platforms and with different Haskell compilers is quite tricky.

To summarize: Please always provide a low-level wrapping that is as
close to the API provided by the OS as possible and then build
convenience functions on top of that.

Cheers,

Johan