Bob wrote: >>>A multi-process model would be a lot more robust overall. [...] If you [...] >>>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. > >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).
Bit more to it than that, unfortunately: - OSA uses Component Manager - not Apple events - to communicate with language components, so the MacPythonOSA component would need to handle each OSA call, stuff its arguments into an IPC message, send the message to the script daemon to process and wait for its response. (This is just the easy bit, btw.) - In addition, the daemon also has to be able to send various messages to the OSA component to be handled there concurrently: CallActiveProc, CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. - Finally, it needs to do all this without any support from the client app and without treading on its toes in any way. And, very preferably, without an onerous IPC overhead that would limit its usefulness. Not trivial, and might get very sticky. Figuring out the details of what's involved and what the potential problems are is beyond my own modest abilities; someone else will have to do all the legwork here. >>>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, Yep, I'm aware of that. The question is how serious those problems would be? Concurrency is less of a problem than usual as OSA scripts are typically executed sequentially; the main issue is when script A imports module X and sets some of its state, then script B imports module X and sets the same state to something else, which will cause A some serious upset the next time it attempts to use it. My goal is for MacPythonOSA to be a great OSA component first, and a great Python second. "Good enough" will be acceptable (after all, it's Python's fault we're in this mess in the first place:p). MacPythonOSA is not a 'standard' Python, and isn't intended to be: it's provided as an alternative to AppleScript and other OSA languages, not as an alternative to other Pythons. It's always going to provide a subset of normal Python functionality by its very nature and has no real application outside of OSA. So if I need to impose a few modest rules regarding usage (e.g. "Thou shalt not open and close the same file handle from different scripts at the same time", which is fair enough) then that may be entirely acceptable. The question is, how difficult will Python make it for users to reasonably follow these rules: will it merely take a modicum of common sense (acceptable), or require intimate knowledge of the inner workings of half of Python (not)? >and there is no way to have separate module namespaces for different code >running in the same interpreter. The only possibility is we could install custom import hooks each time we initialise/call into an OSA script and provide our own non-global module management system. Which might be practical as long as there's only ever one script being executed at a time. Still not an ideal solution though, since it would limit _all_ use to strictly single-threaded. i.e. Some multithreaded clients may open a separate component instance in each of its own threads, allowing it to execute multiple scripts in parallel even when the component language doesn't support threading itself - e.g. AppleScript. Not sure I like the idea of being even worse than AppleScript. All options suck; all we can do is find the one that sucks least intolerably for our needs. :p >Redirecting I/O at all sounds like a bad idea in the first place. stdin/stdout/stderr have no meaning within OSA: stdin is completely redundant; redirecting stdout to the host application as log events is the closest thing that makes sense; and mirroring stderr as log events in addition to its usual behaviour would also be helpful to users (there's no standard 'log error' event AFAIK, unfortunately). Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
