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
