New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signal handling #1368

Open
steveklabnik opened this Issue Nov 12, 2015 · 10 comments

Comments

Projects
None yet
@steveklabnik
Member

steveklabnik commented Nov 12, 2015

Originally filed at rust-lang/rust#11203


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.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Nov 12, 2015

Member

There is the chan-signal crate, which can be used today to listen to signals safely on a channel. It uses the "spin up a thread and wait" approach, so it may not be applicable in all scenarios. The API probably could use some work too.

Member

BurntSushi commented Nov 12, 2015

There is the chan-signal crate, which can be used today to listen to signals safely on a channel. It uses the "spin up a thread and wait" approach, so it may not be applicable in all scenarios. The API probably could use some work too.

@scottlamb

This comment has been minimized.

Show comment
Hide comment
@scottlamb

scottlamb May 17, 2016

fwiw, I see no mention here of "thread-directed" signals. IMHO, it's reasonable to not support them as a first pass (they're a totally different thing than process-directed signals), but worth at least being explicit about what's in scope.

As an example of what these are: let's say I do a mmap of a file and try to read from it but another process has truncated the file so the page I'm reading is no longer valid. A SIGBUS is generated and directed to the thread doing the read. It can't be handled by some other thread using signalfd or the like.

Likewise, SIGFPE, SIGSEGV, SIGILL, SIGPIPE, and anything done with pthread_kill/pthread_sigqueue. The last case is sometimes used as a mechanism for CPU / wall clock profiling tools or thread cancellation.

scottlamb commented May 17, 2016

fwiw, I see no mention here of "thread-directed" signals. IMHO, it's reasonable to not support them as a first pass (they're a totally different thing than process-directed signals), but worth at least being explicit about what's in scope.

As an example of what these are: let's say I do a mmap of a file and try to read from it but another process has truncated the file so the page I'm reading is no longer valid. A SIGBUS is generated and directed to the thread doing the read. It can't be handled by some other thread using signalfd or the like.

Likewise, SIGFPE, SIGSEGV, SIGILL, SIGPIPE, and anything done with pthread_kill/pthread_sigqueue. The last case is sometimes used as a mechanism for CPU / wall clock profiling tools or thread cancellation.

@glandium

This comment has been minimized.

Show comment
Hide comment
@glandium

glandium May 27, 2016

signalfd should be used for everything.

AFAIK, signalfd cannot be used for everything.

glandium commented May 27, 2016

signalfd should be used for everything.

AFAIK, signalfd cannot be used for everything.

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Aug 16, 2016

Relevant article, which also mentions Rust: https://ldpreload.com/blog/signalfd-is-useless

oconnor663 commented Aug 16, 2016

Relevant article, which also mentions Rust: https://ldpreload.com/blog/signalfd-is-useless

@nrc nrc added the T-libs label Aug 19, 2016

@DrRibosome

This comment has been minimized.

Show comment
Hide comment
@DrRibosome

DrRibosome Oct 10, 2016

is there still interest in this being part of rust std? Or, is it expected that client libraries will fill the gap for now/future

DrRibosome commented Oct 10, 2016

is there still interest in this being part of rust std? Or, is it expected that client libraries will fill the gap for now/future

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Oct 10, 2016

Member

I believe we'd still be interested in it being part of the standard library, but we'd like the API to be hashed out in a third party crate first.

Member

sfackler commented Oct 10, 2016

I believe we'd still be interested in it being part of the standard library, but we'd like the API to be hashed out in a third party crate first.

@jD91mZM2

This comment has been minimized.

Show comment
Hide comment
@jD91mZM2

jD91mZM2 May 11, 2017

Any updates on this?
Personally it's no hurries or anything.

I just feel like I should add my comment here supporting including this in the STD. It's a basic feature every language should have. Especially since the current way of doing it requires FFI or a crate which probably also does FFI, which feels like a dirty hack.

jD91mZM2 commented May 11, 2017

Any updates on this?
Personally it's no hurries or anything.

I just feel like I should add my comment here supporting including this in the STD. It's a basic feature every language should have. Especially since the current way of doing it requires FFI or a crate which probably also does FFI, which feels like a dirty hack.

@william20111

This comment has been minimized.

Show comment
Hide comment
@william20111

william20111 Aug 14, 2017

Is there a go to 3rd party crate for dealing with signals? or is it only using libc & unsafe currently?

william20111 commented Aug 14, 2017

Is there a go to 3rd party crate for dealing with signals? or is it only using libc & unsafe currently?

@droundy

This comment has been minimized.

Show comment
Hide comment
@droundy

droundy Aug 14, 2017

I use the ctrlc crate, which is not a complete solution, but is moving towards handling more than just SIGINT.

droundy commented Aug 14, 2017

I use the ctrlc crate, which is not a complete solution, but is moving towards handling more than just SIGINT.

@0xpr03

This comment has been minimized.

Show comment
Hide comment
@0xpr03

0xpr03 commented Jul 13, 2018

currently https://github.com/swizard0/rust-simple-signal seems like the way to go

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