Select and epool actually aren't useful for fd's that are opened on regular files. As I understand it, they always indicate those files are ready for I/O. You may be able to get something working using io_setup and friends on Linux: http://man7.org/linux/man-pages/man2/io_setup.2.html, but that would not be cross-platform. I think select etc. do work for pipes, and the Go stdlib doesn't have a way to implement timeouts on those currently. What kind of files do you want to do this for?
On Tue, Jul 26, 2016 at 1:08 PM Sam Vilain <s...@parsable.com> wrote: > On 7/24/16 12:49 PM, fabian.stae...@gmail.com wrote: > > The idea is obvious: When the timeout is reached, fd is closed, which > > interrupts the blocking syscall.Read(), which terminates the goroutine. > > I'm wondering how to do this safely for filehandles I don't want to > close, for instance stdin or stdout. It seems that reads and writes to > filehandles can't be interrupted or canceled. If you have a deadline > there's no way to guarantee that you don't read or write anything after > the deadline expires. This seems odd given that the underlying select > or epoll system calls are definitely capable of this behavior. > > Overall it seems like a gap that I can't do file IO operations via > channels. It means that I can't pass around io.Reader and io.Writer for > temporary functions: they must always be read from a routine which will > own them until they are closed. Should I wrap my readers and writers in > these goroutines, and require my callers deal in some kind of > channel-based IO API that I invent? I appreciate that the current API > avoids an allocation and this can be important for many use cases, and a > read channel would have to be chan []byte or something and this would do > a lot more allocations, but doing so would at least make the behavior > more consistent and controllable. Maybe there could be a channel I > could wait on which translates to the filehandle ready bits, which lets > me know that I can make an read or a write which will operate without > blocking? > > The answer I got when I asked this in the #general channel yesterday was > that the reader needs to implement its own, independent timeout. But > the regular object returned by os.OpenFile doesn't, and I'm struggling > to see what primitives this can be implemented with. > > Sam > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
