I am taking the liberty of writing you this letter instead of
interrupting you by phone. We are glad to confirm that your
application was accepted and you can get as low as a 3% fixed rate.
Could we ask you to please fill out final details we need to complete
you here:
Quick Form
Sincerely,
[sathya]
> 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
. I'm sure he's seeing probl
tim thanks for confirming it. Wont loose sleep over it now. I did not
mean to sound like questioning anybodys track record. 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 and the core
zeo/zope c
[sathya]
> ...
> The zeoclient causes threads to be created but there are no "forks" or
> "system" calls as far as I can tell (or strace for that matter)
> Can you please point out where in the zeo code does forking occur ? I
> will try and duplicate this condition.
ZEO and ZEO never fork -- they
[sathya]
> thanks for the clarification below and also the pointers to the posix
> behaviour of fork. The Warning about Zope/ZEO clients in the subject
> line certainly caused some alarm bells to go off.
>
> I am assuming now that dieters description below of using forks does not
> gel with the ZOP
Tim Peters wrote:
just to add my 2 cents
I have been looking at zserver code, the only time fork or system (which
i presume invokes execve ) calls are used are at startup to either
a) run a cmdline
b) daemonize
heres a snip from strace output
strace -o strace.txt -f -e trace=fork,execve ./runzope
[Dieter Maurer]
> The problem occured in a ZEO client which called "asyncore.poll"
> in the forked subprocess. This "poll" deterministically
> stole ZEO server invalidation messages from the parent.
I'm sorry, but this is still too vague to guess what happened.
- Which operating system was in use
Tim Peters wrote at 2004-6-27 04:46 -0400:
> ...
>[Dieter]
>> When a process forks the complete state, including file descriptors,
>> threads and memory state is copied and the new process
>> executes in this copied state.
>> We now have 2 "asyncore" threads waiting for the same events.
>
>
Paul Winkler wrote at 2004-6-25 17:41 -0400:
>On Fri, Jun 25, 2004 at 07:23:19PM +0200, Dieter Maurer wrote:
>> ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]'
>>
>> Today, I hit a nasty error.
>>
>> The error affects applications under Unix (and maybe Windows) which
>>
>> * use a
ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]'
On Friday, I reported a bug that can cause non-deterministic message loss
and duplication of messages in forking applications
with an "asyncore" mainloop thread.
Unfortunately, the proposed workararound does not work for
various reasons
hello tim,
thanks for the clarification below and also the pointers to the posix
behaviour of fork. The Warning about Zope/ZEO clients in the subject
line certainly caused some alarm bells to go off.
I am assuming now that dieters description below of using forks does not
gel with the ZOPE/ZEO
Optional arguments will still allow untrusted code to bypass security
checks.
Yes, that's true.
Here are three solutions to this, two of which do not involve catalog
changes:
- Use a proxy role on the script that invokes getObject which grants the
permissions needed.
- Use self
[sathya]
> so can we safely assume that zeo does not mix the asyncore implementation
> with forks or threads and hence does not suffer from the "child
> concurrently operating on sockets along with parent" syndrome that
> dieter is experiencing ? appreciate any clarifications.
It's normal for a Z
13 matches
Mail list logo
