Fw: [another gdesklets kse/libc_r problem]

[Franz Klammer]

Hello!

I sent the message below to gnome@ and someone tells me that
this might here the right list.

the python-code who starts the threads is:

     # Adds and runs a new thread.
     #
     def _add_thread(self, threadfunction, *args):

         # the thread should not start before setup is complete, therefore
         # we are using the GTK idle handler
         def run_thread(threadfunction, args):
             thread.start_new_thread(threadfunction, args)

         gtk.idle_add(run_thread, threadfunction, args)

i'm not subscribed to the list. please add me to the replies.

thanks

franz.

------- Forwarded Message: -------
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
====> hanging here

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.

franz.