I'm forwarding this from the GTK development list. According to Owen
their is something wrong with the threads implementation....
Is that true? or is it a "It's not the way Linux works, so it must be
wrong"-pigheadedness? =)
DocWilco
"ROGIER MULHUIJZEN" <[EMAIL PROTECTED]> writes:
> Hi,
>
> After getting a bit more intimate with FreeBSD's implementation of
> POSIX threads I had another stab at getting gFTP to work.
>
> The problem I had (after fixing a rather simple compile error with
> include files) is that file-transfers (which get their own thread) just
> weren't moving. Except when I was doing stuff with the interface.
>
> After checking gFTP's code I found that all it is rather well coded for
> threading, and was using sleep(0) in all the right places. So I had a
> look at the main loop, which was gtk_main(). Now that (AFAIK) doesn't
> use a sleep(0). So I added it, and presto, gFTP ran as smooth as a
> newborn baby.
>
> What I did exactly was in gtkmain.c at line 476 I added:
>
> if (g_main_is_running (main_loops->data))
> {
> GDK_THREADS_LEAVE ();
> sleep(0);
> g_main_run (loop);
> GDK_THREADS_ENTER ();
> gdk_flush ();
> }
This change doesn't make much sense to me - when there is nothing
for the GUI thread to do, then the GUI thread is blocking in
select(). And if the main thread is blocking in select() and
your other threads aren't running, then you have a bug
in your threading implementation.
But this wouldn't be the right place to put it anyways, since
a) program is free to use g_main_run() directly without going through
gtk_main()
b) gtk_main() is only called once in a typical program, so this
really shouldn't have any effect.
Maybe you can explain more about why you think a sleep(0) is
necessary.
The reason I would expect to see this would be if you had one thread
that was constantly locking and unlocking a lock and you wanted to
give other threads a chance to get scheduled and grab the lock.
But putting a sleep(0) in this spot really shouldn't make any
difference, unless gFTP is constantly running recursive main
loops.
> Now I'm pretty new to GTK's internals, so I'm not sure if the sleep is
> in the right place or not.
>
> The way I figured is:
> - It should NOT be outside the LEAVE/ENTER statements, because they
> translate to unlock and lock mutex. Sleeping after a lock and before an
> unlock seems unhealthy to me
Well, sleeping inside the lock would absolutely no good if the
purpose of your sleep(0) is to give other threads a chance to
grab the lock.
> - The gdk_flush should probably follow the g_main_run(loop) ASAP (not
> sure what it does)
The flush() is basically there makes sure that pending X calls
get done before a program exits. (There is an implicit XFlush()
before GDK goes into a select(), but at this point, there may
be no subsequent iterations, so we need an explicit flush.
Regards,
Owen
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
