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 Sun, Apr 20, 2008 at 10:19 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 19, 2008 at 11:19:14PM -0300, Carlos Ribeiro wrote:
> > 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.
>
> Threads are evil but processes are not - they are completely separated
> and cannot destroy each other's memory. Processes have less problem
> (though
> they still need proper synchronisation).
>
> > 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.
>
> I remember that thread, and Guido resolved that processes are better
> than threads even on multicore CPUs. Multiprocess model with IPC is the
> future of Python (and I wholeheartedly agree with this).
>
> > 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
> > applications?
>
> What problems - except of caching - do you foresee?
>
> Oleg.
> --
> Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED]
> 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.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> sqlobject-discuss mailing list
> sqlobject-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
-------------------------------------------------------------------------
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.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
