Re: Pushing a NULL into g_async_queue

["Alan M. Evans" <ame1 extratech com>]

On Mon, 2005-02-28 at 22:19, James Henstridge wrote:
> Alan M. Evans wrote:
> 
> >Hello all.
> >
> >Is there some good reason for the prohibition on passing NULL data into
> >g_async_queue_push()? I checked the glib sources and the only reason I
> >could find is that data==NULL won't pass the g_return_if_fail(data)
> >test. What is the reason for this seemingly arbitrary limitation?
> >  
> >
> This question is probably better suited to gtk-list or 
> gtk-app-devel-list -- gtk-devel-list is for discussion of development of 
> GTK.

Really? I didn't think that discussion of the implementation details of
glib belonged on either gtk-list nor gtk-app-devel-list. I was actually
cautiously hopeful that this limitation might be lifted.

> In answer to your question, consider the g_async_queue_try_pop() and 
> g_async_queue_timed_pop() functions.  They will either return a value 
> from the queue, or NULL if no items exist.  If you can store NULLs in 
> the queue, then the result becomes ambiguous.

That's a pity. Using GINT_TO_POINTER is a convenient way to pass short
messages through a queue. If I can't find a way to avoid zero as a value
then I'll have to pass a pointer to an int, which means that I now have
to worry about the lifespan of the int. I guess what this means is
g_new(int) at one end and g_free() at the other -- yuck.

Anyway, I don't mean to belabor the point. Hadn't noticed the timed_pop
and try_pop ambiguity when perusing the sources for my answers. Thanks
for the reply.