Re: strange behavior of Glib.Io.read_chars ?

Adrien <[email protected]> Mon, 12 Nov 2012 20:31:04 +0100
Newsgroups gmane.comp.lang.ocaml.lib.gtk
Message-ID <CAP5QFJkX+ABWU_ew=2JzFZMrLXbyRxvBWgU0YC+tcahnTus4Ag@mail.gmail.com>
On 12/11/2012, Pierre Letouzey <[email protected]> wrote:
> Hi
> Thanks for the answer. If this issue is fixed on more recent versions
> that's fine, I'm planning anyway to upgrade my debian in a few weeks.
> Just in case someone wants to investigate more, here's the asked backtrace
> (after installing package libglib2.0-0-dbg :-)
>
> (gdb) bt
> #0  0x00007fda7bf96870 in read () from /lib/libc.so.6
> #1  0x00007fda7c4b9ca2 in g_io_unix_read (channel=0x26ca910, buf=0x27f4340
> "", count=1024, bytes_read=0x7fff1f1ad308, err=0x7fff1f1ad390)
>     at /scratch/build-area/glib2.0-2.24.2/glib/giounix.c:189
> #2  0x00007fda7c46d33c in g_io_channel_fill_buffer (channel=0x26ca910,
> err=0x7fff1f1ad390) at
> /scratch/build-area/glib2.0-2.24.2/glib/giochannel.c:1496
> #3  0x00007fda7c46da76 in IA__g_io_channel_read_chars (channel=0x26ca910,
> buf=0x7fda7ed738c8 ' ' <repeats 200 times>..., count=1000,
>     bytes_read=0x7fff1f1ad398, error=0x7fff1f1ad390) at
> /scratch/build-area/glib2.0-2.24.2/glib/giochannel.c:2045
> #4  0x0000000000524c1c in ml_g_io_channel_read_chars ()
> #5  0x000000000054ae7c in caml_c_call ()
> #6  0x00007fda7ed729f0 in ?? ()
> #7  0x00007fda7ed72a60 in ?? ()
> #8  0x0000000000000000 in ?? ()
>
> So it seems indeed that the program is stuck in a blocking read, for
> whatever reason...
> Well, let's say for now that Glib.Io.read is the winner ;-)

Actually, I tried again and it blocks here too and, here, the backtrace reads:
  0x00007ffff4cf3590 in __read_nocancel () from /lib64/libpthread.so.0
Heh, nocancel.

But checking the Glib docs better, I see no mention of "async" in the
GIO doc. Am I blind (or, well, drunk on one, strong, beer)?

From a quick analysis (don't worry, beer peak is well over now), the
application behaves like it would for regular blocking reads. The
first reads fail so it loops and the subsequent ones don't fail and
probably return with only partial reads. Then, once you've fed 1000
characters to the application, it unfreezes and starts its regular
loop again.

-- 
Adrien Nader