Re: Error converting a pipe (Handler) to fd on vs 2003 to use with g_io_channel_win32_new_fd

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 10 Aug 2009 07:12:53 -0700 (PDT)
puzzlecracker <vehomzzz yahoo com> wrote:
> Using g_idle_add() implies some pretty important things about event
> processing priority that are not implied by the OP.
> 
> Priority is fairly high. Do  I call _idle_add() from a separate
> thread?

It doesn't imply anything.  With g_idle_add_full() you can choose any
priority you like, including G_PRIORITY_HIGH which will put it ahead
of anything else in the event queue, including any GDK drawing
operations (which is not a good idea so I do not recommend that).

g_idle_add()/g_idle_add_full() do exactly what you are trying to do in
long hand, but correctly.  In unix-like operating systems they use a
pipe. In Windows they use a windows event object.

All the glib event loop operations are thread safe provided you have
called g_thread_init(). You are also guaranteed memory visibility as
regards the data argument of g_idle_add() and g_idle_add_full*().  This
is because the main loop has a mutex protecting its event queue.
Adding a new event with g_idle_add() will lock and unlock the mutex.
The dispatching of the event in the main GUI thread will do the same.
You will therefore, at the time of dispatch, have had a release
operation on a synchronisation object by the thread posting the event,
and an acquire operation on the same synchronisation object by the
thread dispatching it.  POSIX and windows both require cache
synchronisation in that case.

Yes, you call g_idle_add()/g_idle_add_full() in the thread wanting to
post an event, and it will execute in the main GUI thread.

Chris