Re: IO Channel Flush - Assertion Failure

[Peter Long <gert2001 yahoo com>]

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 web de>
To: Peter Long <gert2001 yahoo com>
Cc: "gtk-list gnome org" <gtk-list gnome org>
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.
> 
>