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())
os.Exit(1)
}
println("fifo opened")
WaitTillBreak(f)
}
On Sat, Dec 16, 2023 at 9:01 PM Kurtis Rader <kra...@skepticism.us> wrote:
> 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
>
--
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%3DD_AABWxWdQvwnCB%3DK2e4hu3xNM%2BGuO6BtLSrgBML%3Dgoxg%40mail.gmail.com.
