incoming() for NamedPipe

[NikVolf]

is it a good idea to add it so that it matches that api in unix sockets?

https://github.com/tokio-rs/tokio-uds/blob/master/src/lib.rs#L166-L182

[alexcrichton]

Thanks for the report! Unfortunately named pipes don't really work the same way as unix sockets (they're architected quite differently) so an API like incoming doesn't have quite the same translations, so I'm going to close this.

[NikVolf]

@alexcrichton I suppose you know best, but can you tell what is wrong with this approach:

We keep NamedPipe and try to connect it (in non-blocking way) and then replace it with new one and yield original in the Incoming stream?

mostly pseudo-code:

struct Incoming {
   pipe: NamedPipe
}

impl Stream for Incoming {
    type Item = NamedPipe;

   ...

    fn poll(&mut self) -> Result<Async<Option<NamedPipe>>> {
         if try_nb(pipe.connect()) != WOULD_BLOCK { return Ok(Async::Ready(Some(mem::replace(&mut self.pipe, NamedPipe::new(...))); }
         return Ok(Async::NotReady);
    }
}

[alexcrichton]

It's true yeah we could implement it that way but my guess is that it has surprising semantics for those familiar with named pipes already. I'd prefer to have semantics like that in an external crate rather than in the raw bindings here.

For example I think it'd be neat to have a "cross platform IPC" crate with a unix socket-style interface which uses tokio-uds and tokio-named-pipes appropriately under the hood, implementing incoming as you mentioned above.

[NikVolf]

@alexcrichton

did a small prototype with sort of "cross-platform IPC", just wanted to ask, what would be the best approach to unpark this? Does it needs to be parked/unparked there at all?

https://github.com/NikVolf/parity-tokio-ipc/blob/master/src/lib.rs#L147

[NikVolf]

@alexcrichton Just added timeout future there meanwhile, looks unlikely that api allows me to continue Stream based on windows events

[alexcrichton]

@NikVolf oh you can use PollEvented as I believe you just want to wait for an "is writable" notification. That'll get delivered once a client has connected.

[NikVolf]

@alexcrichton but i don't have access to the mio_named_pipes::NamedPipe (which is Evented) from within tokio_named_pipes::NamedPipe, so what can i create PollEvented from?

[NikVolf]

@alexcrichton figured it out, looks like i can just do pipe.poll_write() to get my own poll rescheduled, sorry for lame questions.. :)

[alexcrichton]

Ah yeah that'd do it!