> Dirk Meyer wrote:
>>
>> I just tried two hours to force python to accept other signals -- no
>> way. If you start mplayer, you can't kill it from a shell with -15,
>> only -9 works. If you move the runapp from the runtime into the
>> runtime directory, it works. I also moved the signal part of runapp
>> into a python so file, but it doesn't work that way.
>>
>> Conclusion: I don't like it, but it looks like we need the runapp.
>
> From what I've seen googling around, python blocks signals for threads,
>
> and if these fork, the children end up with blocked signals as well.
> This is supposed to protcet against broken threading implementations.
Yes, this is exactly how it works IIRC. This is why I created runapp.c in
the first place, to unblock the signals so that mencoder etc can be killed
cleanly.
The real problem is that Python does not unblock signals when
popen2.Popen3() etc is used from child threads. But it shouldn't be that
hard to write a python module that mimicks runapp.c, all the system calls
used are available under Python too.
Maybe all it takes is making our own version of Python's popen2.py?
Looking at it I see that it uses /bin/sh to execute applications, which
might explain some of the dll problems with the runtime also.
/ Krister
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
