another gdesklets kse/libc_r problem

[Franz Klammer]

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
>
>