From owner-freebsd-hackers Thu Jan 13 1:28:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtppzh.pzh.nl (webshield.pzh.nl [194.178.168.50]) by hub.freebsd.org (Postfix) with SMTP id E67E615073 for ; Thu, 13 Jan 2000 01:28:34 -0800 (PST) (envelope-from MULHUIJZEN@PZH.NL) Received: FROM smtp.pzh.nl BY smtppzh.pzh.nl ; Thu Jan 13 10:27:43 2000 0000 Received: from PZH40-1-Message_Server by smtp.pzh.nl with Novell_GroupWise; Thu, 13 Jan 2000 10:27:45 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 13 Jan 2000 10:27:23 +0100 From: "ROGIER MULHUIJZEN" To: Subject: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_366F7E81.36573B7A" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: From: Owen Taylor 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: 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: 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" 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