I have Ubuntu 7.10 installed in VMWare. I just checked, O_NDELAY is defined in two places. /usr/include/bits/fcntl.h and /usr/include/asm-generic/fcntl.h. In both cases it is just a synonym for O_NONBLOCK. So I suspect it works differently on Linux than described in that SCO man page. Are you setting O_NDELAY in your code or are you using g_io_unix_set_flags(). I see g_io_unix_set_flags() will use O_NDELAY of O_NONBLOCK in not defined, but it should be in your case, so I don't think this is causing your problems. I assume you are using non-blocking TCP sockets for this channel. So try setting your channel to unbuffered mode and avoid the flush. Then you can handle the case where g_io_channel_write_chars() returns success but writes nothing. You can try, immediately retrying or waiting for a G_IO_OUT event before retrying. Hopefully either of those will work for you. Good luck ----- Original Message ---- From: Christian Bünnig <masala@xxxxxx> To: Peter Long <gert2001@xxxxxxxxx> Cc: "gtk-list@xxxxxxxxx" <gtk-list@xxxxxxxxx> Sent: Tuesday, December 18, 2007 6:18:39 PM Subject: Re: IO Channel Flush - Assertion Failure The following is an excerpt from http://uw713doc.sco.com/en/man/html.2/write.2.html: """"""" When attempting to write to a file descriptor (other than a pipe or FIFO) that supports nonblocking writes and cannot accept the data immediately: If O_NONBLOCK and O_NDELAY are clear, write blocks until the data can be accepted. If O_NONBLOCK or O_NDELAY is set, write does not block the process. If some data can be written without blocking the process, write writes what it can and returns the number of bytes written. Otherwise, if O_NONBLOCK is set, it returns -1 and sets errno to EAGAIN or if O_NDELAY is set, it returns 0. """""""""" So if the flag O_NDELAY is set, 0 should be handled like -1 with errno = EAGAIN (when O_NONBLOCK is set). Time to sleep now .. tomorrow I will check if the socket I am using is set to O_NDELAY. On Tue, 2007-12-18 at 22:30 +0000, Christian Bünnig wrote: > On Tue, 2007-12-18 at 12:03 -0800, Peter Long wrote: > > I agree, there seems to be a bug, the question is where the bug lies. > > I think it is legal for write() to return 0 however I have never experienced > > that myself. Also write() does return -1 if EINTR or EAGAIN occurs. I > > have no idea what conditions would cause it to return 0. I would expect > > a value between 1 and count inclusive where count is the number of bytes > > in the buffer past to write() in the third parameter. > > > > My guess is that the glib code is not where the problem is. Either the OS > > implementation of write() is buggy or there is a subtle bug in your code. > > > > I cannot imagine how you would fix this problem in either g_io_unix_write() > > or g_io_channel_flush(). If write() return's 0 do you just retry the write(), or > > do you make up an error status? It depends on what it means to get back a > > 0 from write(). > > Yep .. until it is not clear if a 0 from write() is legal or what it > means, it is not clear whether and how to alter g_io_unix_write() or > g_io_channel_flush(). > > > Perhaps someone else knows what would cause write() to return 0. > > > BTW: What OS are you using? > > Ubuntu 7.10 with > - libc6-2.6.1 > - glib 2.14.1 > > Just for your info: > The assertion fails rarely, but if it fails, then in the following situation: > > g_io_channel_write_chars(many bytes ~ 60K) > g_io_channel_write_chars(4 bytes) > g_io_channel_flush() <- channel buffer contains 4 bytes at this point > > Channel encoding is NULL. > No idea why it happens in this special situation. > > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
