GIOChannel bug (?)

[Olivier Nenert <onenert condumex com mx>]

Hi all.. 

I (think I) found a bug in glib-1.2.8
It's not a very bad one, and in fact, I'm not even sure it is one after
all,
but if it's not, I think that behavior should be described in the API
documentation.

I write a client application. this application creates clients, connect
them to their respecive servers, and monitor
the comunications with GIOChannels (g_io_channel_unix_new(socket)) 
and watches com events with g_io_add_watch.
I was just watching G_IO_IN, G_IO_ERR and G_IO_HUP.
everything was apparently working fine, because I generally create a
connection, 
or several ones that last until the end of the application itself.
But lately, I've been creating a client, closing it, and creating a new
one.
That's when I started to have some troubles, with pretty weird results.
With some printf debugging,
I could see that, even if the g_io_channel was closed (using
g_io_channel_close), the watcher was not aware of it.
(something like that)
Here is (about it) the client-server process.
The client C1 is created, I check its value (printf("%p", ...))
The client is connected, an io_channel is created and a watcher added,
giving it C1 as a gpointer param.
I write the first request to the io_channel and from the watcher callback,
I receive the answer.
(which takes several watcher callbacks)
then another request is sent, and comes the answer, etc...
I close the client. I didn't have a chance to return FALSE from the watcher
callback, because so far,
everything was just fine. And I don't think I should return FALSE from the
watcher callback, as I explicitly closed
the channel myself.
So, same process, a new Client C2 is created, it has a different value,
which is passed to its new watcher callback.
I write to the channel, sending the request.
The answer, as always arrives in several reads. the thing is, the first
part of the message,
(the first next time the watcher callback is called) the callback is called
with THE LAST parameters valu. which is C1,
instead of C2.
as it looks like a normal operation though, I still don't return FALSE, and
in the next gtk_iteration, 
the watcher callback is executed again. (and again and again). but from now
on, it holds the correct C2 value as data.

I really think it's a bug, as I didn't see documented the "correct" way to
handle this situation.
Anyway, the "correct" way to handle it, is to return FALSE from the watcher
at the right time, ie, when the channel is closed.
so I have to add the G_IO_NVAL option to the g-io_add_watch, 
and the callback will be called with this condition when the channel is
closed, 
giving a chance to return FALSE at this moment. everything works just time
after that.

I'd like to know if it's actually a bug or not :)
(or maybe it's just somthing I missed from the doc, but..)

cheers..

Olivier.