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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
