On Apr 10, 2005, at 3:53 PM, has wrote:
A multi-process model would be a lot more robust overall. Linking to Python is problematic if there's even a remote possibility the process might also be using a Python interpreter.
If you remove the need for that and communicate with existing Python interpreters exclusively, it would probably be much better overall (though much more work).
Yep, removing Python from the component would require quite a lot more in C, which I'm not keen on for maintenance's sake. Even if each script runs as a seperate process, I really want the OSA component and script daemon to remain written in Python where it's manageable. Besides, I'm simply not willing to pursue it as a sizeable C project myself - I've other things to do - so if C-ifying it is the only option then someone else will have to adopt it.
Not as much extra code as you'd think. The easiest way to do it would be as an apple event "router". You receive the events from the OSA interface, start up a Python process running code that can accept apple events from your router (if it's not already running), and then toss the events to the correct process (each component instance could correspond to a pid, maybe).
Threading sounds like a bad idea, given the constraints on them, the difficulty to do it correctly, and the pain they are to debug when not behaving correctly.
Yep, I suspect there's no easy solution and it's going to be a struggle either way. Stupid Python. Just how painful are Python threads anyway (sub-interpreters specifically)?
The only other option would be to find some way to provide each script with an independent module namespace and std I/O objects despite Python's global obsession, in which case we could safely run all scripts in the main thread (still not ideal, but good enough for most situations). I've no idea if that's practical or not though; it'd need someone familiar with Python's internals to answer it.
Nope, not practical. Sub-interpreters are going to cause problems with extension modules, and there is no way to have separate module namespaces for different code running in the same interpreter. Redirecting I/O at all sounds like a bad idea in the first place.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig