Go team does acknowledge [1] it as a bug, so there is some point here
However, that said, I wonder if OP (duckdb) could have written their solution [2] differently. Shouldn't they be able to select from a Pipe as well as Error channel simultaneously? (similar to how they are doing it inside here [3]). If not, I would have create a go-routine that does blocking read on the Pipe and then pass it on to another channel to select on.
I’m not sure you can. Both the Open() and Read() calls will block. You can select() on a pipe but not on open. I haven’t checked to see if you can select on a non blocking fd though. This is what the go wrappers do behind the scenes.
I seem to remember non-blocking io with named pipes was unreliable, in the sense that the test suite of whatever-it-was (memory is reeealy sketchy, this was tens of years ago) would fail randomly often enough that we had to throw the easy solution away and do actual networking.
A bit like the .signature named pipe from fortune thing, where sometimes you got two signatures and sometimes none? Anybody remember that?
harikb|2 years ago
However, that said, I wonder if OP (duckdb) could have written their solution [2] differently. Shouldn't they be able to select from a Pipe as well as Error channel simultaneously? (similar to how they are doing it inside here [3]). If not, I would have create a go-routine that does blocking read on the Pipe and then pass it on to another channel to select on.
[1] https://github.com/golang/go/issues/66239
[2] https://github.com/scratchdata/scratchdata/blob/7c1a0fcd0e20...
[3] https://github.com/scratchdata/scratchdata/blob/7c1a0fcd0e20...
memset|1 year ago
o11c|2 years ago
chipaca|2 years ago
A bit like the .signature named pipe from fortune thing, where sometimes you got two signatures and sometimes none? Anybody remember that?