Re: gdk_threads_leave in gtk callback ?



Gus Koppel wrote:

There shouldn't be any additional buffer copying required just because
dealing with it moves from one thread to another. You know, all threads
have the same access to all program data.

Yes, but in my case buffers are reused to recv next packets from network, so
copying (or waiting, but this adds extra delays) is still necessarily.

More reasonable would probably be to copy just pointers to the buffers
between threads. For instance, provide just two pointers like these:

gchar *text_for_msg_box;
gchar *text_to_add;

Most of the time they'll be NULL. The main thread occasionally checks
whether they have become non-NULL, for instance within an idle or
timeout handler. If they have, then that handler (in the main thread)
either displays a message box or adds the text to your windows. When
finished, it clears the pointers again. They would be set by the other
thread(s) only, of course.

Thanks, this is good way. I'm also thinking about using GAsyncQueue to avoid
unneeded delays in network code.

Slightly more sophisticated buffer management might be necessary if you
expect new data to come in and be handled by the other thread while for
instance a message box is being open. However, necessary measures are
the same, no matter whether you display the message box from within the
main thread or from any other thread.

BTW, can I use g_idle_add in non-main thread without locking ?

I am not sure. The documentation is not clear about this and I havn't
had the time to examine the sources of that yet. To be safe, you should
wrap a simple GStaticMutex lock around the call.

OK.

Again, thanks a lot for your attention.

-- 
             Vladimir




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]