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 m
> 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 practi
> 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 varia
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 isn't,
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 m
> >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 mo
> Dan Sugalski 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.
>
> i.e. not so much 'threaded' as 'stitched up'.
Well, py
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,
>
> 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
> 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 outsid
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-platfo
11 matches
Mail list logo
