On 5/28/07, Robert Pearce <rob@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gtk-list > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
