On Fri, Jul 18, 2008 at 5:45 PM, John Goerzen
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