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.
