You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 5157 Reporter: kaustuv Assigned to:@mshinwell Status: resolved (set by @mshinwell on 2016-12-07T16:39:48Z) Resolution: fixed Priority: normal Severity: feature Version: 3.12.0 Category: ~DO NOT USE (was: OCaml general) Monitored by:@ygrek@glondu@hcarty@dbuenzli
Bug description
There is apparently no way to go back and forth between the signal numbers defined in the Sys module and native signal numbers without breaking the caml API. This prevents the Unix module from being cleanly extended with non-POSIX signal operations, such as adding support for signalfd(2) on Linux.
This seems to have dropped off the radar. I just recently ran into this problem again when I had to bind a C library that does signal munging of its own. The fix is almost too trivial for words, but I've attached a patch nonetheless.
I understand that changing the caml api should not be done lightly as you limit your options for changes in the future. However, this particular feature of signals.h has been stable for a very long time.
Original bug ID: 5157
Reporter: kaustuv
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2016-12-07T16:39:48Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 3.12.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @ygrek @glondu @hcarty @dbuenzli
Bug description
There is apparently no way to go back and forth between the signal numbers defined in the Sys module and native signal numbers without breaking the caml API. This prevents the Unix module from being cleanly extended with non-POSIX signal operations, such as adding support for signalfd(2) on Linux.
File attachments
The text was updated successfully, but these errors were encountered: