On Sun, 30 Sep 2001, Hong Zhang wrote:
How does python handle MT?
Honestly? Really, really badly, at least from a performance point of view.
There's a single global lock and anything that might affect shared state
anywhere grabs it.
One way to reduce sync overhead is to make more
Now how do you go about performing an atomic operation in MT? I
understand the desire for reentrance via the exclusive use of local
variables, but I'm not quite sure how you can enforce this when many
operations are on shared data (manipulating elements of the
interpreter / global
On Sun, Sep 30, 2001 at 10:45:46AM -0700, Hong Zhang wrote:
Python uses global lock for multi-threading. It is reasonable for io
thread,
which blocks most of time. It will completely useless for CPU intensive
programs or large SMP machines.
It might be useless in theory. In practice it
At 10:45 AM 9/30/2001 -0700, Hong Zhang wrote:
The same story may happen to Perl. If Perl make all operations on SV, AV,
HV sync, the performance will be pathetic. Many SMP machines can only
perform about 10M sync operations per second, because sync op requires
system-wide bus lock or global
How does python handle MT?
Honestly? Really, really badly, at least from a performance point of view.
There's a single global lock and anything that might affect shared state
anywhere grabs it.
Python uses global lock for multi-threading. It is reasonable for io thread,
which blocks most of
At 09:51 AM 9/29/2001 -0400, Michael Maraist wrote:
I generally divide signals into two groups:
*) Messages from outside (i.e. SIGHUP)
*) Indicators of Horrific Failure (i.e. SIGBUS)
Generally speaking, parrot should probably just up and die for the first
type, and turn the
I generally divide signals into two groups:
*) Messages from outside (i.e. SIGHUP)
*) Indicators of Horrific Failure (i.e. SIGBUS)
Generally speaking, parrot should probably just up and die for the first
type, and turn the second into events.
I don't know. SIGHUP is useful to
In a word? Badly. :) Especially when threads were involved, though in some
ways it was actually better since you were less likely to core perl.
Threads and signals generally don't mix well, especially in any sort of
cross-platform way. Linux, for example, deals with signals in threaded
At 10:46 AM 9/28/2001 -0700, Hong Zhang wrote:
In a word? Badly. :) Especially when threads were involved, though in some
ways it was actually better since you were less likely to core perl.
Threads and signals generally don't mix well, especially in any sort of
cross-platform way.
The fun part about async vs sync is there's no common decision on what's
an
async signal and what's a sync signal. :( SIGPIPE, for example, is one of
those. (Tru64, at least, treats it differently than Solaris)
I generally divide signals into two groups:
*) Messages from outside
10 matches
Mail list logo
