Re: gdk_io_* clarification

[Owen Taylor <otaylor redhat com>]

James Macnicol <jamesm@evans.ee.adfa.oz.au> writes:

> [big snip]
> 
> > It's not the ref count on the file descriptor per se,
> > but the ref count on the GSource that was created
> > to handle the IO watch.
> > 
> > This only should happen after a call to gdk_input_remove()
> > 
> > (Though it won't necessarily be invoked _within_ the call to 
> > gdk_input_remove(), especially if that call is made within
> > your input function)
> > 
> > Can you come up with a (hopefully short...) example of
> > when this is happening?
> 
> 	I'll go into a little more detail about what it does ... if that 
> isn't sufficient I can try to make an example but I'm not sure I can do
> a short one...
> 
> 	I am writing an NNTP implementation for the Usenet News reader I'm
> creating.  Commands are generated and responses are read only after the user
> has done something with the GUI so I have notification of write-ready only
> turned on when issuing a command, i.e.  most of the time I am monitoring
> the socket with
> 
> gdk_input_add_full(fd, GDK_INPUT_READ, ...)
> 
> 	but when the user wants to send a command to the server I do a
> gdk_input_remove() on that file descriptor and immediately call
> 
> gdk_input_add_full(fd, GDK_INPUT_READ|GDK_INPUT_WRITE, ...)
> 
> 	(I probably don't need read notification here, but I leave it on
> all the time) and then turn it off after the command has been sent.
> 
> 	What I see is the program will read the greeting string from the
> server but after the file descriptor is setup to ask for notification of
> write-ready status it just stops.  The change in notification status does
> occur in the handler that is called when data is first ready to be read
> from the server.
> 
> 	In summary,
> 
> 1. Program asks to be notified of data ready to read
> 2. Data becomes available
> 3. Handler that was registered with gdk_input_add_full is called
> 4. Data is read
> 5. Program now asks for read and write notification (still in handler)
> 6. Handler returns
> 7. Destroy notify is called (for reasons I don't understand)
> 8. Program just sits there forever

The destroy notify sounds perfectly fine to me ... you call 
gdk_input_remove() on a input handler that you added with
gdk_input_add_full() and when the callback remove, your DestroyNotify
is called. 

I'm not completely sure why the program should "sit there forever"...
If you strace the process, is it selecting on the appropriate
file descriptors?

My best guess is that it has more to do with networking then
with what GLib is doing, but then again, I don't know if
anybody has ever tested GDK_INPUT_WRITE out (though it
is hard to imagine what would go wrong with it)
 
> 	I'm a bit suspicious that the gdk_input_remove(),
> gdk_input_add_full() method of changing the notifications on that file
> descriptor but I don't see any other way to do it.

Why not use separate GDK_INPUT_READ and GDK_INPUT_WRITE handlers?

(You can have any number of handlers for the same fd)

> 	BTW, I assume that leaving write notification on all the time is
> a bad thing.  This gets called continously when the program is idle and
> sounds a bad as continuous polling to me.  I would've thought it would be
> much better to turn this on only when you need it and to turn it off again
> straight away.

Yeah, continuous write notification probably a bad thing.
(I'd almost say doing non-blocking writes is probably
more trouble than its worth, considering the small size
of typical commands and buffering, but then again, I
don't really know what the usage patterns are here)

Regards,
                                        Owen