Re: Data available for reading in a GIOChannel
- From: "Jonathan Winterflood" <jonathan winterflood gmail com>
- To: paul linuxaudiosystems com
- Cc: gtk-list gnome org
- Subject: Re: Data available for reading in a GIOChannel
- Date: Tue, 29 May 2007 22:20:20 +0200
Thanks for your precisions on where this difference comes from :)
I guess g_io_channel_set_flags(_channel, G_IO_FLAG_NONBLOCK, NULL); is good for switching to non-blocking mode.
A question arises, though: is it possible that the channel will recieve the last of the data between the time g_io_channel_read_chars returns G_IO_STATUS_AGAIN and the callback exits, and that the callback will not be called again?
This would be a really easy way to get stuck waiting for data which is already there, so I'm thinking no, can you confirm this?
Thanks a lot,
Paul Davis <paul linuxaudiosystems com> wrote:
On Mon, 2007-05-28 at 17:26 +0200, Jonathan Winterflood wrote:
> > you never know how much readable data is available until you read
> it, you are only ever guaranteed to have one byte of data available
> for reading anyway.
> In my opinion, the channel should _always_ know how much data is
> available, how can it tell that there is nothing there?... Plus, it
> can't not know the amount of data it _has_ actually recieved and is
> buffered ready for me...
there is a very big difference between knowing the distinctions between:
* something and nothing
* specifically how much and nothing at all
the process that leads to the callback is called as soon as a single
byte of data arrives. there might be more data by the time it actually
executes. nothing else in the system (except perhaps a device driver) is
buffering data for you and then saying (post-facto) "we have some
stuff". your callback can do that if it wants to offer that kind of
service to high level layers of your application/code.
> Java InputStreams for example have the available() method:
thats because Java InputStreams are heavily buffered. glib/gtk
IOChannels are not, by default. in particular, when you use this
callback method, your code is being notified that there is data
available long before a Java InputStream would have told that it had
> > [...] I read the data in 1024 byte chunks [...]
> This sounds like a good workaround, which will work well in a watch
> callback; I'll use that
the important thing is just to use non-blocking I/O with the channel. t
<Morpheus> linux, c'est une question de VI ou de MORE
] [Thread Prev