-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.P-mediumMedium priorityMedium priority
Description
This involves filling out libnative/io/mod.rs
, but this is also a very tricky issue. Right now the API is wrapped around what libuv provided for us, but that may not be the best API to have.
Dealing with signals is always an incredibly tricky topic, and here's the ideas for what should possibly happen:
- on linux (maybe android?)
signalfd
should be used for everything - on windows, basically just do whatever libuv does and pray that everything works
- on everything else, we're going to have to resort to
sigaction
. I believe that the best way to deal with this is libuv's trick of a self-looping pipe (the signal handler writes the signal onto a pipe which is read in the "event loop"). This will certainly involve some trickiness.
It has also been brought up that there are primitives like sigwait
on unixes which can be used to just block a thread when waiting for "some group of signals", but the API which we have created for signals cannot wrap this functionality. We could add a similar function for libgreen/libnative, but I personally don't think it's worth it. It is worth some discussion, however.
Metadata
Metadata
Assignees
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.P-mediumMedium priorityMedium priority
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
alexcrichton commentedon Feb 3, 2014
Nominating.
pnkfelix commentedon Feb 6, 2014
Assigning P-high, not 1.0.
aturon commentedon Jun 3, 2014
cc me. I'm interested in working on this one.
[-]Signal handling needs a 1:1 implementation[/-][+]implement signal handling[/+]l0kod commentedon Nov 11, 2014
It would be great to be able to handle signals per task. This way we could send interrupt events to running tasks (e.g. to exit a blocking syscall).
Maybe a channel-like interface could allow to extend the OS-specific signal types with custom types/objects.
l0kod commentedon Nov 29, 2014
This could be an interesting abstraction of
sigqueue
.l0kod commentedon Nov 29, 2014
About signal receiving, a nice
signalfd
implementation could return aSignal
struct wrapping anIoHandle<Fd>
(cf. #19169) which could create aReceiver
(withevent()
) usable withselect!
.Signal
could then exposeSigInfo
structs through anIterator
interface.l0kod commentedon Mar 21, 2015
cc Safe async/reentrant closure
steveklabnik commentedon Nov 12, 2015
Pretty sure this would go through the RFC process these days, as it's pretty huge, so moving over there rust-lang/rfcs#1368