On Sun, Oct 10, 2021 at 10:33:07AM +0200, Andreas Wacknitz wrote: > > Hi, are there any news about this bug and its fix?
That patch didn't work. Neither did the next dozen or so. However, I did learn a great deal about glib. I know what the cause is. I just don't have the solution yet. One of the causes is the nature of the EAGAIN error. In the context of hald and glib on OI, the read() system call within glib produces this error when the pipe is empty, but the other end of the pipe is still open for write. Every subsequent read() will produce the same error until the process at the other end actually writes something to the pipe. This error is converted to G_IO_STATUS_AGAIN by glib. hald only processes lines when the status returned by g_io_channel_read_line() is G_IO_STATUS_NORMAL . It ignores any others, including G_IO_STATUS_AGAIN . The other cause is that lines written by hald (with the write() system call) to the pipe all end with "\n\0". Yes, the trailing null is written to and read back from the pipe. However, hald does not set the line terminator as glib expects, instead relying on glib's automatic line ending determination. In this case, that appears not to work. Instead, glib does a second read, which always sets the status to G_IO_STATUS_AGAIN . Once set, this status replaces any previous status. As you can see, hald writes lines to the pipe with write() but reads them back with g_io_channel_read_line(). That design may be a third cause. I'm going to do a bit more testing with hald and glib, and then return to what I was doing with OI. -- -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada- _______________________________________________ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev