> tim thanks for confirming it. Wont loose sleep over it now. I did not
> mean to sound like questioning anybodys track record.

No, it didn't sound like you were.  I mentioned that Dieter has an
excellent track record because *I'm* giving him a hard time here
<wink>.  I'm sure he's seeing problems, but I'm frustrated by the lack
of concrete information about how they were provoked and on which kind
of system.

> Since we have ZEO clusters in production it raised alarm bells thats all. Its good
> to know the problem MAY occur only if u fork in your own app code

A potential problem is that Unixish systems typically fork "under the
covers" for things that look utterly harmless to an application writer
-- like the os.system() and os.popen() Dieter mentioned.  fork()ing
can create horrible problems for threaded applications (which is
essentially *why* POSIX only clones the thread calling fork() -- that
creates problems too, but the POSIX spec I referenced before discusses
all this, so I won't repeat it here).

> and the core zeo/zope code by itself is not contributing to it.

I don't think they are, but there's still not enough info here to say for sure.

> I guess as a general rule of thumb its not a good idea to use forks in zope
> application or product code anyway (unless you know what you are doing.)

A more general rule of thumb is to avoid forking a threaded
application of any kind.  It's easy to follow that rule on OSes that
don't have fork <cough>, but unfortunately tricky to avoid on those
that do have fork.
Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to