Date: Wed, 26 Nov 2003 10:24:59 +0100 From: Franz Klammer <klammer@webonaut.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: another gdesklets kse/libc_r problem Message-ID: <3FC4716B.4050504@webonaut.com> In-Reply-To: <1069796889.743.75.camel@gyros> References: <3FC0D95D.8080007@webonaut.com> <1069796889.743.75.camel@gyros>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FC4716B.4050504>