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): > > https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin.go > > That you mentioned "unix.Select" in your first message does not change the fact that we were left to assume you meant golang.org/x/sys/unix rather than some other "unix" package. Sure, that assumption was likely correct but, again, don't require people to make such assumptions. > > - unit test producing this behavior, differing between Linux and > macos: > > https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin_test.go > > That should suffice as a minimal example. "go test -v ./pipe -ginkgo.v" > gives details as the test progresses. > I copied your code at https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin.go, changed the package to "main", added a "func main()" and tested it. It works identically on Linux and macOS. I did this test by running "mknod p p" in one terminal and having my copy of your code open that file for reading in a second terminal. I then executed "sleep 1 > p" in the first terminal. I got the same behavior on Linux and macOS. So I assume your unit test is flawed. I only glanced at your unit test but the sleeps and goroutines without any explicit synchronization (e.g., using a sync.WaitGroup) look to me like a source of non-deterministic behavior. Your expectation of the behavior of your "WaitTillBreak()" function might also be incorrect. A file descriptor open for reading on a FIFO becomes readable when there is data available to be read or the write side of the FIFO is closed. And it is not at all clear why you named it "WaitTillBreak"; even with the comment "checks a fifo/pipe to see when it breaks." A fifo/pipe doesn't "break". It either has at least one open fd for writing or not; in which case the last writer has closed its end of the fifo/pipe. It's not "broken". It simply has entered an EOF condition for the reader since no more data will be sent. Are you using the named pipe solely as a semaphore rather than to send data? That is an atypical use for a named pipe. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD877DXFFzn2u5yJyAGnr1ODfg7qwGXRcMu%2ByM0kDN93QA%40mail.gmail.com.
