Re: Data available for reading in a GIOChannel
- From: "Alexandre Moreira" <alexandream gmail com>
- To: GTK-List <gtk-list gnome org>
- Subject: Re: Data available for reading in a GIOChannel
- Date: Mon, 28 May 2007 16:42:11 -0300
On 5/28/07, Robert Pearce <rob bdt-home demon co uk> wrote:
On Sun, 27 May 2007 16:57:03 +0200 Jonathan wrote:
> Hi,
>
> I need to read a large amount of data from a GIOChannel (200K, over
> the internet).
>
> So far, I use the gnet library to create the
> socket, and then I use the GIOChannel to integrate the read/writing
> into the program's loop (a
> GTK application)
>
> I use g_io_add_watch(_channel, G_IO_IN, &(_imageDataReadyForReading), this);
> to register the callback for data reading.
>
> How can I determine the number of bytes available for reading, so as not to
> block on reading the data?
>
On the applications where I've used g_io_add_watch it's on a serial port that I've opened non-blocking. Then my callback I just does:
stat = g_io_channel_read_chars ( source,
tmpbuf, sizeof(tmpbuf), &len, &err );
If there are less than tmpbuf characters waiting, it fills what it can and sets len to the actual number. Then I process len bytes. Normally my tmpbuf is bigger than the longest message I expect, but it seems to work even if it isn't.
Please anyone correct me if I'm wrong, but...
I guess you should loop until EAGAIN, because you can get some nasty
things if your program is being run on a system where the select (or
poll, or whatever it uses to watch the channels) call returns when the
file descriptor CHANGES its state (ready to read // not ready to
read).
In that case you could create a situation where a client is expecting
for some response from you, but you didn't actually read the request
(because it is lost in the buffer) and therefore each process is
waiting for the other to act.
Regards,
Alexandre Moreira.
_______________________________________________
gtk-list mailing list
gtk-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]