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 second into events.
>
>I don't know. SIGHUP is useful to capture. Not to mention, how else
>would you maintan Perl5 compatibility $SIG{HUP}. If you're a daemon,
>sighup is good to restart off of.
I got the relative reference wrong. We should die on Horrible Failures and
turn the messages into events.
>I'm seriously doubting that you're going to get a fully portable
>threading model. One size doesn't fit all. Usually that's something
>that the JIT would take care of (hense my preoccupation with
>fake-threads)..
If you winnow things down, one size does fit all. All threading
implementations need some form of blocking lock, and some way to go to
sleep pending a wakeup from another thread. Everything else is gravy, and
you don't really need it to implement threads in parrot. (The JIT doesn't
do us any good here, since we still need to define a model that parrot
implements and layer that on top of the platform native threads. JIT just
makes things go faster)
>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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
