Re: multi-threaded apps.

Ian Campbell <> writes:

> On Fri, 18 Aug 2000, James Henstridge wrote:
> > 
> > On Fri, 18 Aug 2000, Ian Campbell wrote:
> > 
> > > > Well, the gtk_signal_emit function is a gtk function, so you should grab
> > > > the lock before calling it.  So if you want to emit a signal from an idle
> > > > or timeout function, you will need to do GDK_THREADS_ENTER() and
> > > > GDK_THREADS_LEAVE() around the gtk calls.
> > > > 
> > > 
> > > Thats exactly what I wanted to know... Thank you... For some reason I
> > > wasn't considering gtk_signa_emit to be a  a gtk function. Duh!
> > > 
> > > I expect I should use the lowercase variants though ?
> > 
> > Well, the lowercase versions are just functions that call the upper case
> > macros.  I don't know what the policy is on which set you should use.  It
> > would be better to ask that on a gtk list.
> I got the impression that you should use the uppercase ones within GTK
> (for performance) and the lowercase one in apss, so that a build-time
> config mistake in your app doesn't cause things to go wrong, because the
> lowercase versions are correct for how GTK+ was built.

I think I had some such idea when I added both variants, but since I
left the macros in the public header files, they have the same
guarantees for useablility in apps as the function.

Which one should you use? Well, my expectation is that the function
call produces smaller code, the macro faster code. How much
smaller? How much faster? You'd have to experiment to find out.

The macro expands to something like (pseudocode):

 if (gdk_threads_mutex && g_threads_initialized)
   (*g_thread_functions.lock) (gdk_threads_mutex);

My opinion - in 99% of cases, it just doesn't matter. Toss
a coin. 


[ Providing the authoritative, but useless answer ]

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