On Mon, 2007-05-28 at 17:26 +0200, Jonathan Winterflood wrote: > Hi, > > > 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: > http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available() 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 information ready. > > [...] 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
