When you think in terms of shallow-reaching request handling, where you're doing little more than running an app that hauls some data out of a database, templates it and spits it back out, forking the same app for every request would be enough.
Hi Cliff, The above paragraph does explain my current requirement. I do want to avoid state data between requests in my server side handlers. At this stage I also don't see why I'd need communication between my handlers, since I'd let the database enforce it's "rules" upon each handler. So I'll take that approach for now (forking per connection handler) and maybe look at a threaded version later if needed and if I can easily make the single core framework components re-entrant (see this topic
http://forums.puremvc.org/index.php?topic=539.0).
I suppose my initial question could be rephased to ask if the lack of a multicore framework for Python is going to hold me back. Which you effectively answered for me thank you.
Being a PureMVC newbie (only just skimmed over your idioms doco and hardly written any AS3 code) I'm am still left wondering if a multicore Python implementation would (if it existed) have any beneficial purpose? Firstly frequent unit testing in Python is just no problem what so ever. I can appreciate (or guess) that defining cores in a framework context would make good sense in terms of code clarity, but if the only other advantage of the multicore framework is being able to start/stop independent cores and allow them to reliably communicate when running, then I see Python being able to do that already (under a parent/child process system), and at a later date via threads if a few fixes are made to Toby's current codebase.
-Emmett