Re: [gnet-dev] on the handling of refs in gnet

[David Helder <dhelder umich edu>]

On 20 Sep 2002, Ian Peters wrote:
> For example, gnet_tcp_socket_get_iochannel (aside: why iochannel and not
> io_channel, as glib does things?) refs the GIOChannel before returning
> it to the caller, which is unconventional (see g_main_loop_get_context
> as an example).  The most common use of _get_iochannel, as far as I can
> tell, will be:
>
> g_io_add_watch (gnet_tcp_socket_get_iochannel (socket), ...)
>
> The watch itself refs the GIOChannel as long as it's in effect (so that
> you can handle lifecycle of the GIOChannel entirely by adding a watch,
> then unreffing it, and later returning FALSE from the watch function,
> which removes the other ref on the GIOChannel, freeing it).  Currently
> in gnet, you have to save the channel in a local variable, add a watch
> on it, and then unref it:
>
> channel = gnet_tcp_socket_get_iochannel (socket);
> g_io_add_watch (channel, ...);
> g_io_channel_unref (channel);
>
> In other cases, you may be storing the channel locally in some kind of
> state.  In this case, you explicitly note that you're keeping a ref in
> the channel by writing:
>
> state->channel = gnet_tcp_socket_get_iochannel (socket);
> g_io_channel_ref (state->channel);


The intent was that the socket owned the iochannel and the user should not
close and unref it directly.  Ref'ing it before returning it was an
attempt to enforce this, though I can see that it'd be hard to remember to
unref something if it was never directly refed.

The best solution may be to not ref the iochannel at all.  Users could
still ref and unref it if they'd like.  But I can't breaking binary
compatibility until the next minor version.

I don't remember why "io_channel" is "iochannel" in GNet.  It makes more
sense too me.  Still, it's more important to be consistent with GLib, so I
will add that to the TODO list for the next minor version.


> The other interesting case comes up for e.g. asynchronous connect
> callbacks.  When the user supplied callback function is called, the
> socket and inetaddr have a ref count of 1, but the callee is expected to
> _unref them if they are unwanted -- rather than being expected to _ref
> them if they want to keep them.  Ideally, in
> gnet_tcp_socket_connect_tcp_cb (tcp.c:150), right after calling
> state->func, both the socket and the inetaddr should be unref'd, freeing
> them unless the callback function ref'd them explicitly.  Otherwise,
> most connect callback functions have to gnet_inetaddr_unref the addr,
> for example, because few use it outside of the function.

The common case is that the user wants the socket - they called the
function in the first place.


David


-- 
      __          _    __ David Helder - dhelder umich edu
  ___/ /__ __  __(_)__/ / <http://www.eecs.umich.edu/~dhelder>
 / _  / _ `/ |/ / / _  /  Jungle Monkey: <http://www.junglemonkey.net>
 |_,_/|_,_/|___/_/|_,_/   Paper CD Case: <http://www.papercdcase.com>