Re: [go-nuts] unix.Poll weirdness

[Dan Kortschak]

Thanks for the very clear explanation, Ian.

I figured there was something like that. It turns out I was using a fifo
badly (I was trying to model a sysfs attribute - clearly incorrectly as
I now find out that poll should wait on POLLPRI for sysfs attributes).
The original problem is now solved.

On Thu, 2016-09-15 at 20:07 -0700, Ian Lance Taylor wrote:
> Opening a FIFO for reading blocks until some process opens the FIFO
> for writing.  So your program is not testing what you think it is
> testing.  In the case where you don't open the FIFO for writing, the
> program simply blocks as os.Open before it ever calls poll.  In the
> case where you do write to the FIFO, the program blocks in Open until
> the write, then records the time, runs poll which finds something to
> read, and then prints the time it took to call poll.
> 
> One way to fix this is to use
> os.OpenFile(*path, os.O_RDONLY|syscall.O_NONBLOCK, 0)
> 
> Ian


-- 
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.

Re: [go-nuts] unix.Poll weirdness

[Ian Lance Taylor]

On Thu, Sep 15, 2016 at 6:41 PM, Dan Kortschak
 wrote:
> I am in the process of adding sysfs polling support for a physical
> device and I'm using a small Go program
> (https://play.golang.org/p/5v8DsGv6Dk) to help test whether what I'm
> doing is working (it's not yet).
>
> In doing this, I've found somethings that I don't understand with the
> golang.org/x/sys/unix.Poll behaviour (possibly poll(2) in general).
>
> If I make a fifo, "test" and then invoke the program above on it with a
> timout of one second I would expect that the program would terminate
> after about a second with POLLIN not set due to the timeout (maybe this
> is something I am misunderstanding - is the timeout not referring to the
> amount of time poll will wait on an event for?).
>
> The second issue is that if I do write to the other end of the fifo
> after some time, the program terminates as expected, but the delay
> printed is invariably shorter than expected. For example,
>
> $ (sleep 10; echo foo >test)& ./poll -timeout 10ms -path test
> [1] 4566
> n=1 err= delay=5.313µs flags=00010001 (POLLIN=true POLLERR=false)
> foo
> [1]+  Done( sleep 10; echo foo > test )
>
> Printing to get an idea of what is happening doesn't help, since nothing
> prints to the terminal until after the Poll call has returned.
>
> I'm using ubuntu 14.04 and Go1.7.1.

Opening a FIFO for reading blocks until some process opens the FIFO
for writing.  So your program is not testing what you think it is
testing.  In the case where you don't open the FIFO for writing, the
program simply blocks as os.Open before it ever calls poll.  In the
case where you do write to the FIFO, the program blocks in Open until
the write, then records the time, runs poll which finds something to
read, and then prints the time it took to call poll.

One way to fix this is to use
os.OpenFile(*path, os.O_RDONLY|syscall.O_NONBLOCK, 0)

Ian

-- 
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.