Date: Thu, 13 Jan 2000 10:27:23 +0100 From: "ROGIER MULHUIJZEN" <MULHUIJZEN@PZH.NL> To: <freebsd-hackers@freebsd.org> Subject: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Message-ID: <s87da8a1.029@smtp.pzh.nl>
next in thread | raw e-mail | index | archive | help
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_366F7E81.36573B7A
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
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
--=_366F7E81.36573B7A
Content-Type: message/rfc822
Received: from smtppzh.pzh.nl
(webshield.pzh.nl [194.178.168.50])
by smtp.pzh.nl; Wed, 12 Jan 2000 20:28:46 +0100
Received: FROM lists.redhat.com BY smtppzh.pzh.nl ; Wed Jan 12 20:28:01 2000 0000
Received: (qmail 20818 invoked by uid 501); 12 Jan 2000 19:24:54 -0000
Resent-Date: 12 Jan 2000 19:24:53 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-devel-list-request@redhat.com Wed Jan 12 14:24:53 2000
X-Authentication-Warning: fresnel.labs.redhat.com: otaylor set sender to otaylor@fresnel.labs.redhat.com using -f
To: gtk-devel-list@redhat.com
Subject: Re: GTK & threading on FreeBSD (and possibly other unices)
References: <s87ccb1e.048@smtp.pzh.nl>
From: Owen Taylor <otaylor@redhat.com>
Date: 12 Jan 2000 12:37:20 -0500
In-Reply-To: "ROGIER MULHUIJZEN"'s message of "Wed, 12 Jan 2000 18:42:14 +0100"
Message-ID: <ybebt6rchtb.fsf@fresnel.labs.redhat.com>
Lines: 76
User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"RfAIQ2.0.g45.5KDVu"@lists.redhat.com>
Resent-From: gtk-devel-list@redhat.com
Reply-To: gtk-devel-list@redhat.com
X-Mailing-List: <gtk-devel-list@redhat.com> archive/latest/538
X-Loop: gtk-devel-list@redhat.com
Precedence: list
Resent-Sender: gtk-devel-list-request@redhat.com
X-URL: http://www.redhat.com
"ROGIER MULHUIJZEN" <MULHUIJZEN@PZH.NL> 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 gtk-devel-list-request@redhat.com with
"unsubscribe" as the Subject.
--=_366F7E81.36573B7A--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s87da8a1.029>