> 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
> 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 -