Hi,
> > > I can't imagine how a web server cannot be affected by apps creating
> > > threads and/or proccesses. Think about memmory use, resource
> > > pooling, syncronization issues, ... remember a child process ot
> > > thread prevents the termination of its parent (which may become a
> > > zombie on Unix systems, and a zombie still holds its open file
> > > handles).
> >
> > This is wrong. Parents *can* terminate with running children, and
> > zombie processes take up no resources other than a process table slot.
This isn't (or weren't) the case in all posix systems. But I may be wrong on
this specif topic.
> In addition I don't think that if thread A spawns thread B that thread A has
> to wait until thread B terminates before it can itself terminate. Why would
> this be the case? Threads to not necessarily have the same parent child
> relationships that processes do.
But we are talking about Java and PHP, two cross-plataform development
languages, and abot PostgreSQL, which also supports many pltaforms (although no
as much as java and php).
This kind of generalization about OS capabilites may be dangerous, unless you
really know your specific target can handle this well.
But it'll be more dangerous the fact that most programmers out there don't have
a solid background on concurrent programming. It's not their falt, it's a very
difficult topic, and very hard to debug. I'd prefer not using it at all if I do
have other alternatives to solve the problem. After all, Information Systems
and web portals usually aren't about high-degree paralelism, numeric-intensive
computations. :-)
There are also optimization questins for high-volume (many concurrent users)
sites and apps. Threads and processes is not an abundant resource (not when you
are speaking of hundreds or even thousands). The time spent creating them is
also not negligible in these cases.
Why do you thing Apache and PostgreSQL limit the maximum active, simultaneus
procceses, and Tomcat limits the number of working threads? They use
proccess/thread pooling to achieve performance and scalability withot
compromising reliability. If you do start your own threads (or processes) you
may face the same issues the developers of these servers faced.
Why not using a message-oriented middleware, who will take care of these? Even
if you write your own daemon, it'll be easier to work these issues on a
centralized background app than on a number of web apps.
[]s, Fernando Lozano
