Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

On Thu, Dec 21, 2023 at 5:40 PM Steven Hartland wrote: > poll and select for this behavior was broken in FreeBSD up until 195423 > was committed as detailed > by this bug report > . > > Given

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

poll and select for this behavior was broken in FreeBSD up until 195423 was committed as detailed by this bug report . Given the MacOS and FreeBSD have related history I wouldn't be surprised

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

The issue is also reproducible using Python3 on macOS, whereas it works as expected once again on Linux; just for reference here's the corresponding SO question . To a

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

It actually *does *work (again, there's a unit test as well as working code for five years now), but good to know that it is actually useless, so this is something to remove as part of the usual maintenance chores. On Sunday, December 17, 2023 at 6:43:51 AM UTC+1 Kurtis Rader wrote: On Fri,

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

Please note that the unit test I linked to tests on the "writing end" of the pipe. In fact, I wrote in the OP right in my first sentence: > *Hi, I need to detect on the producer side (writing end) of a named pipe when the consumer (reading end) has disconnect/closed. * I'm afraid, but you are

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

On Fri, Dec 15, 2023 at 7:13 AM 'TheDiveO' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I'm opening both named pipe ends as follows (in different processes): > > os.OpenFile(fifoname, os.O_WRONLY, os.ModeNamedPipe) > os.OpenFile(fifoname, os.O_RDONLY, os.ModeNamedPipe) > Passing

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

I should probably clarify that my copy of TheDiveO code simply added the following function and replaced the use of github.com/sirupsen/logrus with println. func main() { f, err := os.OpenFile("p", os.O_RDONLY, 0) if err != nil { println("open p", err.Error())

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

On Sat, Dec 16, 2023 at 7:54 AM 'TheDiveO' via golang-nuts < golang-nuts@googlegroups.com> wrote: > >- implementation using unix.Select (btw, I explicitly mentioned >unix.Select in my OP): > >

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

- implementation using unix.Select (btw, I explicitly mentioned unix.Select in my OP): https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin.go - unit test producing this behavior, differing between Linux and macos:

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

It is also more likely, but not certain, that the bug is in your code rather than the macOS kernel or the https://pkg.go.dev/golang.org/x/sys/unix#Select Go code. Which is why it is important to actually show us the code you wrote. I've been programming for a living since 1979 and have written a

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

Do not make us guess what your code looks like and which packages you are using. I'm guessing you are using https://pkg.go.dev/golang.org/x/sys/unix#Select but I shouldn't have to do so. You should be able to show us a minimal reproducible example of code that illustrates a problem of this nature.

[go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

Hi, I need to detect on the producer side (writing end) of a named pipe when the consumer (reading end) has disconnect/closed. This detection needs to work "quickly" even if the producer doesn't produce anything; thus, SIGPIPE wouldn't help. On Linux, when using unix.Select() on the fd of the