Re: [rust-dev] Any way to wake up rust task?
There is no way to generically wake up or kill a task, it must be arranged via some other means for the task to wake up. For TCP connections, you can use the close_read() method or the set_read_timeout() methods. In 0.10, this was not implemented (we recommend you use master). On Thu, May 15, 2014 at 3:43 PM, Paul Colomiets p...@colomiets.name wrote: Hi, I have a few kinds of tasks like the ones reading from a TCP socket or listening for TCP connections, that need to be shut down when unneeded. How can I wake up/kill a task waiting for data in Reader.read() method or similar? In the master branch I can set_timeout and wake up once a while (which seems like ugly hack too) In 0.10 there is no even timeouts. Is there any way to interrupt or kill a task? -- Paul ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Any way to wake up rust task?
Hi Alex, Sorry for replying off-list, previously. I would try to argue on the both points: On Fri, May 16, 2014 at 2:09 AM, Alex Crichton a...@crichton.co wrote: There is no way to generically wake up or kill a task, it must be arranged via some other means for the task to wake up. Is this intentional or just not implemented yet? Intentional, I don't think we plan on implementing this any time soon, if at all. Waking up on timeout is hardly a good decision. Let's think about thousands of connections, each waking up at a reasonable timeouts (sometimes between 100 ms to 1 sec for my taste). The close_read is a hack that doesn't work for many cases (listening sockets, pipes, SCTP sockets, etc.) I'm not sure what the API should be. A way to poll on two sockets, or on socket and channel simultaneously may work for me. Similarly it may be an ability to kill the task. Or a way to send an interruption signal (similar to EINTR). For TCP connections, you can use the close_read() method or the set_read_timeout() methods. In 0.10, this was not implemented (we recommend you use master). Ok. BTW, why close_xxx and set_xx_timeout are not a part of some trait? (they might be reused at least for TcpStream and UnixStream) The methods are all implemented for both TcpStream and UnixStream, I opted to not put them on a trait because I didn't think the trait would serve much purpose. In theory you could take T: Reader + Interruptible, but it seemed like you would more often just take TcpStream/UnixStream specifically. Well, I think many networking applications would like to work with both TCP and Unix sockets. As a recent example docker uses HTTP protocol over unix socket by default (this is a prominent example, as many HTTP implementations designed without this in mind). And Stream trait is not enough for them because they need timeouts too. -- Paul ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Any way to wake up rust task?
Waking up on timeout is hardly a good decision. Let's think about thousands of connections, each waking up at a reasonable timeouts (sometimes between 100 ms to 1 sec for my taste). The close_read is a hack that doesn't work for many cases (listening sockets, pipes, SCTP sockets, etc.) I'm not sure what the API should be. A way to poll on two sockets, or on socket and channel simultaneously may work for me. Similarly it may be an ability to kill the task. Or a way to send an interruption signal (similar to EINTR). I agree that waking up a task arbitrarily blocked at any location is quite useful. It is also a significant amount of implementation to do so, and we do not plan on doing so at this time. Things like selection over sockets would likely come with an async I/O library which is planned for post-1.0 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
