wrapping libuv signal for use in Rust #9318

minhnhdo · 2013-09-19T04:30:39Z

This pull request aims to create a wrapper for libuv's signal handling for use in Rust. Although it is still in an early stage, early feedback is much welcomed.

alexcrichton · 2013-09-19T06:00:44Z

This looks pretty good from a libuv-bindings perspective, but currently there is no safe method to use this. Right now you could register a handler, and then forget to unregister it, causing possible leaks or use-after-free situations.

I'm not entirely certain about the semantics of our &fn vs ~fn types, but it seems like perhaps there should be some safe bindings which have a destructor which un-registers the handler. Something along the lines of:

let handler = io::signal::Handler::new(SIGINT, || {
  println("look, I got a sigint!");
});
handler.install();
// handler is un-registered when it is destroyed.

Basically the main takeaway is that the main purpose of rt::io is to provide safe bindings to all the libuv functions. That's the main bulk of what still needs to be done for this pull.

thestinger · 2013-09-19T06:20:41Z

An example of how to implement a useful/safe signal handling API is the Go standard library's signal package:

http://golang.org/pkg/os/signal/

The task can ask for a pipe on which to receive signals, and select on it. I expect you could also make a standalone signal object to select on.

alexcrichton · 2013-09-19T07:33:40Z

I actually always thought that Go's signals were pretty slick. We're definitely going to want selection over a number of events at some point, and if signals could fit into that list, it would be awesome.

minhnhdo · 2013-09-19T07:52:09Z

@alexcrichton uv_signal_init requires a uv_loop_t*. Could you tell me how to get one?
@thestinger I was using Go's documentation as a reference

alexcrichton · 2013-09-19T07:59:17Z

YOu can get the uv_loop_t from the IoFactory or one of the related instances of that.

minhnhdo · 2013-09-19T08:58:37Z

@alexcrichton, @thestinger could you give me an example of how selection would work?

alexcrichton · 2013-09-19T16:33:27Z

I'm not entirely sure because I've never used them before, but it appears that you may be interested in src/libstd/select.rs

minhnhdo · 2013-09-21T04:03:32Z

src/libstd/rt/io/signal.rs

+            None => {
+                let chan = self.chan.clone();
+                let handler = ~do Handler::new(signum) |_, signum| {
+                    chan.send(signum);


SharedChan doesn't like send()ing in a scheduler context (rtassert! triggered at src/libstd/rt/comm.rs:118). It seems that extern "C" fns are executed in the scheduler context (?). I have also tried to task::spawn a new task and send() in that task instead, but task::spawn requires that it be called in a green task context (rtassert! triggered at src/libstd/task/spawn.rs:561). Could you point me to a fix, @brson ?

I came across this quite a bit in a branch i was spiking related to async IO (ended up getting dropped).

anyways.. the people i spoke to (I believe @toddaaro and/or @anasazi) indicated that that barrier to sending from a SchedTask was artificial..

@olsonjeffery could you please confirm if I can delete the rtassert!?

IIRC, There actually are two things that need to happen:

remove the rtassert!

use send_deferred instead of send(that's what will actually cause a segfault if you send from a SchedTask

Can someone else verify this COA, though? @alexcrichton @brson ?

Sadly I know very little about the runtime, so I won't be much help here :(

@olsonjeffery I did not remove the rtassert!. However, I switched to using SharedChan<T>::send_deferred() instead of SharedChan<T>::send() and the rtassert! isn't triggered any more.

minhnhdo · 2013-09-24T04:52:24Z

r?

alexcrichton · 2013-09-24T16:54:09Z

Signal handling is historically an incredibly tricky thing to get right. I would imaging that a lot of "the magic" is taken care for us by libuv, however.

It would be nice to have very explicit documentation about the exact behavior of the signal handling in order to clarify what exactly it means to receive a signal. Right now there's a few things in this pull I think are missing. Some of them may just require clarification, but they should all be thought about and considered.

What happens if two handlers are registered for the same signal?
There should certainly be tests.
What happens if a signal is received and no one is listening?
What happens if signals are received when previous ones have not been processed?

Those are the ones that I can think of off the top of my head, and I think that others would be alleviated with some more extensive documentation about the signal handling.

thestinger · 2013-09-24T16:59:05Z

Especially if you register a handler for the same signal in different schedulers (threads) on a platform without signalfd.

minhnhdo · 2013-09-28T10:13:20Z

@alexcrichton Whenever I do make check TESTNAME=src/libstd/rt/io/signal.rs, it always reports 0 test in test result. Could you tell me what I am doing wrong?

alexcrichton · 2013-09-28T20:27:50Z

I'm not sure if TESTNAME works for unit tests, I normally run make check-stage1-std and then run the binary by hand with the string to filter on.

huonw · 2013-09-29T01:09:28Z

TESTNAME does work, but the --test test-runners filter by Rust name, not file path, so make check-stage1-std TESTNAME=rt::io::signal should work.

minhnhdo · 2013-09-29T09:24:47Z

@huonw thanks. It works.
Is there any way to force the scheduler to send all data sent by send_deferred()?

minhnhdo · 2013-10-02T01:14:43Z

need-info r?

brson · 2013-10-16T21:36:02Z

It's a shame to let this keep sitting. Do we know what needs to happen to merge this?

thestinger · 2013-10-16T21:37:16Z

@brson: I'm worried that LLVM isn't implementing this in a way that's safe with multiple libuv instances around, and haven't looked into it deep enough to know for sure.

minhnhdo · 2013-10-16T23:39:26Z

@thestinger Could you elaborate? How can I check for this concern?

alexcrichton · 2013-10-16T23:45:27Z

I think that this is still missing the documentation necessary at the top of the file in docblocks or associated with the various functions as well. Additionally, I'm still not sure what the answers to a couple of my above questions are, so would you be willing to write up some documentation explaining what's going on?

minhnhdo · 2013-10-17T00:03:05Z

@alexcrichton I'm on it

alexcrichton · 2013-10-19T00:47:44Z

src/libstd/rt/io/signal.rs

+    Interrupt = 2i,
+    Break = 21i,
+    HangUp = 1i,
+    WindowSizeChange = 28i,


Could you add some documentation for when each of these signals are generated? It would also be useful to mention their posix equivalents (if they exist)

alexcrichton · 2013-10-19T01:05:15Z

I was looking into libuv's implementation, and they appear to handle most of my concerns, so I'm not too worried about the semantics of signal handling. It looks like everything here is essentially "what we'd want to do" in the sense that it's all the right plumbing. The more concerning part to me is that the libuv types and implementation are exposed directly to rt::io. This needs to be reorganized to follow the same layout as the rest of the implementations of I/O in rt::io.

That would involve making an Rtio type inside of rt::rtio and then adding a method to IoFactory. Inside of rt::uv::uvio you would then implement the Rtio type for some Uv type (which does much of this internally), and then everything is wrapped up and exposed through rt::io::signal in a wrapper which uses the IoFactory to create an object. Also, the return value of Listener::new should be Option<Listener> because there may be no local IoFactory.

I can touch up the documentation afterwards, I'm mostly concerned about the organization right now. Again, sorry this took awhile to get to, but now I feel like I'm up to speed with the runtime and feel comfortable doing an actual review :)

minhnhdo · 2013-10-19T02:49:20Z

@alexcrichton thank you for this detailed review. I will fix it up and make a commit shortly.

minhnhdo · 2013-10-19T04:35:18Z

r?

alexcrichton · 2013-10-19T17:31:38Z

src/libstd/rt/io/signal.rs

+    }
+}
+
+impl GenericPort<Signum> for Listener {


I'm a little unfamiliar with our concurrency primitives, but I imagine that doesn't expose the ability to select over the port receiving the signal, right? I think that it would be ok if port was a public field accessible by consumers of the api so the full functionality of the port could be leveraged.

alexcrichton · 2013-10-19T17:48:02Z

This is looking good, nice work!

I had a few comments about how I think the EventLoop api should get reorganized, and I think that would draw a clearer boundary of what's responsible for what. That would push the Handler structure down into uvio (where I think it belongs), and a little more error handling would get exposed through the eventloop interface.

Again though, thanks for doing all this, it's sorely needed!

minhnhdo · 2013-10-21T11:08:42Z

@alexcrichton thank you for your kind words. I have pushed the changes. r?

alexcrichton · 2013-10-21T16:59:59Z

src/libstd/rt/rtio.rs

@@ -154,3 +159,7 @@ pub trait RtioPipe {
    fn read(&mut self, buf: &mut [u8]) -> Result<uint, IoError>;
    fn write(&mut self, buf: &[u8]) -> Result<(), IoError>;
 }
+
+pub trait RtioSignal {
+    fn signal(&mut self, signal: Signum, channel: SharedChan<Signum>) -> Result<(), IoError>;


Let's not expose this as a function on the trait, but rather leave it up to the implementation. It's a little odd to have a blank trait, but I think that it's proper for now.

alexcrichton · 2013-10-21T17:02:56Z

Looking really good! Would you mind adding a test for the case I mentioned earlier, along with a test which generates an error when you attempt to listen on an invalid signal?

descriptive names easier-to-use api reorganize and document

minhnhdo · 2013-10-22T09:39:26Z

@alexcrichton since there is an EventLoop trait already, I assume you meant to add to this one. Changes pushed. r?

alexcrichton · 2013-10-22T15:44:01Z

Looks great to me! I'm going to merge this along with #9901 in order to reduce the number of merge conflicts it's going to cause, thanks again!

alexcrichton · 2013-10-22T15:52:29Z

Thanks again for this! (still in the process of merging, but it'll be up on #9901 soon)

minhnhdo · 2013-10-22T17:24:37Z

@alexcrichton thanks 👍

Fix if_let_mutex not checking Mutexes behind refs Fixes rust-lang#9193 We can always peel references because we are looking for a method-call, for which autoderef applies. --- changelog: [`if_let_mutex`]: detect calls to `Mutex::lock()` if mutex is behind a ref changelog: [`if_let_mutex`]: Add labels to the two instances of the same Mutex that will deadlock

minhnhdo reviewed Sep 21, 2013
View reviewed changes

alexcrichton reviewed Oct 19, 2013
View reviewed changes

alexcrichton reviewed Oct 21, 2013
View reviewed changes

wrapping libuv signal for use in Rust

7197fec

descriptive names easier-to-use api reorganize and document

alexcrichton closed this Oct 22, 2013

wrapping libuv signal for use in Rust #9318

wrapping libuv signal for use in Rust #9318

Conversation

minhnhdo commented Sep 19, 2013

alexcrichton commented Sep 19, 2013

thestinger commented Sep 19, 2013

alexcrichton commented Sep 19, 2013

minhnhdo commented Sep 19, 2013

alexcrichton commented Sep 19, 2013

minhnhdo commented Sep 19, 2013

alexcrichton commented Sep 19, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

minhnhdo commented Sep 24, 2013

alexcrichton commented Sep 24, 2013

thestinger commented Sep 24, 2013

minhnhdo commented Sep 28, 2013

alexcrichton commented Sep 28, 2013

huonw commented Sep 29, 2013

minhnhdo commented Sep 29, 2013

minhnhdo commented Oct 2, 2013

brson commented Oct 16, 2013

thestinger commented Oct 16, 2013

minhnhdo commented Oct 16, 2013

alexcrichton commented Oct 16, 2013

minhnhdo commented Oct 17, 2013

Choose a reason for hiding this comment

alexcrichton commented Oct 19, 2013

minhnhdo commented Oct 19, 2013

minhnhdo commented Oct 19, 2013

Choose a reason for hiding this comment

alexcrichton commented Oct 19, 2013

minhnhdo commented Oct 21, 2013

Choose a reason for hiding this comment

alexcrichton commented Oct 21, 2013

minhnhdo commented Oct 22, 2013

alexcrichton commented Oct 22, 2013

alexcrichton commented Oct 22, 2013

minhnhdo commented Oct 22, 2013