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 <[email protected]> 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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to