The "problem" IMHO is with long running processes. Short-lived processes, in the CGI (and now Google AppEngine) style, should have no problems. Long running processes keep lots of data in memory, and keeping it in sync is very hard. It can be nearly as hard as doing threads right. That was the case I was worried about.
But thinking again, you're probably right and this is going to be a non-issue. Few applications today rely on long running processes. Most servers can be implemented efficiently in terms of a "service request" model, using short lived processes. This leaves desktop applications, but that's also changing.
It's curious and a bit frustrating. Threads are potentially much more efficient and faster than processes, but are so hard to get right. Perhaps it's just that we got threads because CPUs were slower. Now CPUs are getting fast enough to run entire processes as fast as we expected a threaded program to run. Time to move on?
On Sat, Apr 19, 2008 at 11:19:14PM -0300, Carlos Ribeiro wrote:Threads are evil but processes are not - they are completely separated
> But the fact is that today you have to deal with parallelism in one form or
> another. It can be threads or multiple processes, it's unavoidable. And it
> will get worse with newer CPUs.
and cannot destroy each other's memory. Processes have less problem (though
they still need proper synchronisation).
I remember that thread, and Guido resolved that processes are better
> Your argument reminds me of a recent post by Guido van Rossum. If I remember
> it right it was one of the posts regarding Python 3k, someone asked if there
> were any plans to remove the GIL. Guido said that the someone wrote a patch
> to remove the GIL. It was very complex and the performance was poor, because
> of the number of extra checks. In the end it became impossible to keep the
> patch synchronized with the development on the main Python trunk.
than threads even on multicore CPUs. Multiprocess model with IPC is the
future of Python (and I wholeheartedly agree with this).
What problems - except of caching - do you foresee?
> Back to the original question, wich asked about a how to for SQLObjects and
> threads. I believe the same question can be applied if you resort to
> multiple processes. What's the best way to do it, specially for long running
Oleg Broytmann http://phd.pp.ru/ firstname.lastname@example.org
Programmers don't die, they just GOSUB without RETURN.
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
sqlobject-discuss mailing list