From owner-freebsd-gnome@FreeBSD.ORG Wed Nov 26 01:25:06 2003 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C4CC16A4CE for ; Wed, 26 Nov 2003 01:25:06 -0800 (PST) Received: from sv02.webonaut.com (kirk.webonaut.com [212.41.243.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C49A943FA3 for ; Wed, 26 Nov 2003 01:25:04 -0800 (PST) (envelope-from klammer@webonaut.com) Received: from localhost (localhost [127.0.0.1]) by sv02.webonaut.com (Postfix) with ESMTP id 13B7B76421; Wed, 26 Nov 2003 10:25:02 +0100 (CET) Received: from sv02.webonaut.com ([127.0.0.1]) by localhost (sv02.webonaut.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33875-02; Wed, 26 Nov 2003 10:24:59 +0100 (CET) Received: from webonaut.com (sisko.webonaut.com [212.41.243.28]) by sv02.webonaut.com (Postfix) with ESMTP id DF3A27641F; Wed, 26 Nov 2003 10:24:58 +0100 (CET) Message-ID: <3FC4716B.4050504@webonaut.com> Date: Wed, 26 Nov 2003 10:24:59 +0100 From: Franz Klammer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031021 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <3FC0D95D.8080007@webonaut.com> <1069796889.743.75.camel@gyros> In-Reply-To: <1069796889.743.75.camel@gyros> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at webonaut.com cc: FreeBSD GNOME Users Subject: Re: another gdesklets kse/libc_r problem X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 09:25:06 -0000 Joe Marcus Clarke wrote: >On Sun, 2003-11-23 at 10:59, Franz Klammer wrote: > >>at least under -current i've following threads-problem: >> >>when a sensor doing commands.getstatusoutput(cmd) >>out of a thread the first call works like expected, but >>the second call will result in a deadlock (i think). >>what i've found in the last days was that it happens while >>commands.getstatusoutput -> pipe.read() >> >>if added a print "1.... "+cmd bevore getstatusoutput and >>a print "2 ... "+cmd after. heres the output if i start >>gdesklets from a terminal-window: >> >>1 ... /bin/date '+%a %d %b %y'|iconv -t UTF-8 >>2 ... /bin/date '+%a %d %b %y'|iconv -t UTF-8 >>1 ... /bin/date '+%a %d %b %y'|iconv -t UTF-8 >> >> >>that problem only occours with libc_r but not with libkse. >> >>also with libc_r a ps fax | grep gdesklets looks like this: >> 80390 p4 S+ 0:05,58 python /usr/X11R6/bin/gdesklets >> 80431 p4 S+ 0:00,00 python /usr/X11R6/bin/gdesklets >> 80446 p4 S+ 0:00,00 python /usr/X11R6/bin/gdesklets >> >>with libkse there is only one line. >> >>i'm out of ideas now. >> > >Is this on 5.x? The more I think about this, the more it sounds like > yes it's 5.x: 5.2-BETA FreeBSD 5.2-BETA #11: Tue Nov 25 12:10.03 CET 2003 >the "dreaded thread" problem where by -lc_r is not passed to the linker >on all versions of FreeBSD. gdesklets seems to be safe, but I'm not >sure if this particular sensor needs compiled code. > > not sure. because if i played around with the desklets i've changed the installed .py-files and when i run gedesklets as normal user python didn't use the outdated (pre-)compiled versions. ok! i didn't changed all sensors. only sensor/Sensor.py and Sensors/ExternalInterval/__init__.py. just for info - (so far i can remember) i've tried following: - recompile python with WITH_HUGHE_STACK_SIZE - reqrite Sensor.py to use threading instead of threads - use py-pexpect instead of getstatusoutput - a alternate version of popen found from google in commands::getstatusoutput() ¹) - playing around with thread-(un)locking before/after getstatusoutput - playing with gtk.threads_enter & gtk.threads_leave - add a random sleep-time before starting the threads (because i've found something in the Changelog from python about starting some threads to fast in series.) ¹) http://groups.google.com/groups?selm=3A83D8FF.A90F4E4A%40ebioinformatics.com and isn't python still an interpreting language even with .pyc or pyo - files? i guess there is a problem with python (or py-{gtk|gnome|...}) or maybe with the internal compiler from or python at all. i didn't have a 4.x desktop pc available therefore i can't test it. but because i suppose there is actually no problem with the psi-sensors i think i will send it for commit in the next days. franz. >Joe > >