Skip to content

implement signal handling #11203

@alexcrichton

Description

@alexcrichton
Member

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.

Activity

alexcrichton

alexcrichton commented on Feb 3, 2014

@alexcrichton
MemberAuthor

Nominating.

pnkfelix

pnkfelix commented on Feb 6, 2014

@pnkfelix
Member

Assigning P-high, not 1.0.

aturon

aturon commented on Jun 3, 2014

@aturon
Member

cc me. I'm interested in working on this one.

changed the title [-]Signal handling needs a 1:1 implementation[/-] [+]implement signal handling[/+] on Oct 2, 2014
l0kod

l0kod commented on Nov 11, 2014

@l0kod
Contributor

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

l0kod commented on Nov 29, 2014

@l0kod
Contributor

Maybe a channel-like interface could allow to extend the OS-specific signal types with custom types/objects.

This could be an interesting abstraction of sigqueue.

l0kod

l0kod commented on Nov 29, 2014

@l0kod
Contributor

About signal receiving, a nice signalfd implementation could return a Signal struct wrapping an IoHandle<Fd> (cf. #19169) which could create a Receiver (with event()) usable with select!.

Signal could then expose SigInfo structs through an Iterator interface.

l0kod

l0kod commented on Mar 21, 2015

@l0kod
Contributor
added
C-enhancementCategory: An issue proposing an enhancement or a PR with one.
on Mar 25, 2015
steveklabnik

steveklabnik commented on Nov 12, 2015

@steveklabnik
Member

Pretty sure this would go through the RFC process these days, as it's pretty huge, so moving over there rust-lang/rfcs#1368

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.P-mediumMedium priority

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@alexcrichton@pnkfelix@aturon@l0kod

        Issue actions

          implement signal handling · Issue #11203 · rust-lang/rust