RE: poll with timeout 0 in main loop

[Juan Pablo L. <jpablolorenzetti hotmail com>]

Hi Chris, yes it works without setting it as non-blocking so i decided to leave none blocking just in case .. 
:) .... anyways
i was preparing the test code to send to you guys but i discovered that in the test code the cpu usage is 0% 
(as i would expect in the real application)  ... the code i was going to send was a stripped version of the 
original code so that ... but there is something that might be very important but have not mention yet . i 
also created a GSource to run functions in other main loops (for example i use this to fire the connection 
cleaning code in the server when a connection dies) asynchronously, anyways, this is makes me very suspicious 
now:

static gboolean async_callback_prepare(GSource *p_source,int *p_timeout)
{
    AsyncCallbackSource *async_source = (AsyncCallbackSource *)p_source;
    gboolean ret;

    *p_timeout = 0;
    g_mutex_lock(async_source->mutex1);
    ret = g_queue_is_empty(&async_source->callback_list);
    g_mutex_unlock(async_source->mutex1);

    return !ret;
}
   


i think i misunderstood the documentation here and maybe this is the "0" being passed to poll ???  i think i 
will test this in the real code and let you know asap ....



> Date: Fri, 22 Oct 2010 14:27:54 +0100
> From: chris cvine freeserve co uk
> To: chris cvine freeserve co uk
> CC: jpablolorenzetti hotmail com; gtk-app-devel-list gnome org
> Subject: Re: poll with timeout 0 in main loop
>
> On Fri, 22 Oct 2010 13:53:55 +0100
> Chris Vine <chris cvine freeserve co uk> wrote:
>
> > On Fri, 22 Oct 2010 10:37:01 +0000
> > Juan Pablo L. <jpablolorenzetti hotmail com> wrote:
> > > i attached the code but did not make thru, here is the server code:
> >
> > Something odd is going on.
> >
> > I see you are using GIOChannel not to do any reading, but in order to
> > notify you that a connection is available.  poll()/select() of course
> > support this in unix-like systems, but I don't know if GIOChannel
> > does (I have never tried). Possibly it only works if you set the
> > channel as non-blocking with g_io_channel_set_flags() rather than by
> > manipulating the file descriptor directly, which you have done.
> > Again, I don't know.
>
> Actually, in this usage (attaching the file descriptor of a listening
> socket to a main loop) there is no need to make the file descriptor
> non-blocking since you will not make any blocking calls on it until you
> actually get to call accept() to establish the connection, and you may
> get undefined behaviour if you do - I don't know what POSIX says about
> that when you attempt to use poll() with it.  Once poll() indicates
> that a connection is available, accept() can't block anyway.
>
> Does it work if you omit your call to fctl()?
>
> Chris