develooper Front page | perl.perl5.porters | Postings from August 2001

Re: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
Dan Sugalski
August 22, 2001 07:29
Re: [PATCH] Adding callbacks to the core
Message ID:
At 04:02 PM 8/22/2001 +0200, Arthur Bergman wrote:
>01-08-22 15.30, skrev David M. Lloyd på följande:
> > On Wed, 22 Aug 2001, Arthur Bergman wrote:
> >
> >> 01-08-22 14.56, skrev David M. Lloyd på följande:
> >>> I changed the code to share the async check with signals; therefore there
> >>> will be no speed difference in the default case.  However, I will do some
> >>> benchmarking anyways just to satify the crowd.
> >>
> >> How does it affect performance one signals occur. This is in the
> >> hottest part of the hot path of perl.
> >
> > In the normal case, just like before, there is one comparison per opcode.
> >
> > When perl gets a signal and there are no active callbacks, for ONE opcode,
> > there will be four comparisons instead of one, a mutex lock if you have
> > i?threads enabled, and an assignment.  Since signals are relatively
> > infrequent, this should be OK.
>Whoa, not for ONE opcode, for each and every opcode. Why do you need to do
>so many comparions and lock the mutex if perl gets a signal.

Unless I missed something, it's only for the first time a signal is 
processed, at which point the flags are cleared and you don't pay until the 
next event.

> >> I would stronly recomend against using perl with a threaded program
> >> without compiling with threads or ithreads. You will be probably link
> >> against the wrong c library.
> >
> > Understood; however, often people (like me) will link their Perl against
> > -lpthreads even if we aren't going to use threads, so we can link against
> > libraries that do safely.
> > Which brings up a point; maybe we should have a define/Configure thingy
> > for linking to threads without using them, and making a version of mutexes
> > that are available to these programs?  That would be cool.
>Just compile with useithreads.

If you don't need multiple concurrent interpreters, why pay the overhead? 
Building perl with MULTIPLICITY enabled isn't at all free. Granted, with 
threads built in you pay the OS overhead for threading, but perl's 
responsible for a significant fraction of the speed penalty.

> >> You are not mutexing in the dispatch loop, which means that if the
> >> next is disabled during the exeuction of the current dispatching
> >> callback, all the following ones are not called.
> >
> > Read it again...  I'm grabbing the value of 'next' *before* calling the
> > callback.  I've been over this code many times with the goal of not having
> > to put mutexes in, and it should be 100% safe.  See the logic:
> >
> > 1. If there is at least one callback waiting, process callbacks.
> > 2. (for loop):
> > 1. Put head in cur.
> > 2. Check to make sure cur isn't NULL (in case callback went away)
> > 3. Grab next item into next, so that next callback doesn't go away.
> > 4. Call current callback; it can enable/disable whatever it wants
> > without affecting anything crucial.

I'm not sure this is safe. (I'm pretty sure there's something wrong with 
it, but I can't put my finger on it) Depending on ordering's a bad thing 
generally when dealing with async/threaded code, since many processors 
don't make many execution ordering guarantees, you may get interrupted in 
the middle of things if a signal or other interrupt occurs, the C compiler 
may reorder when optimizing, and threaded code can potentially be executing 
on multiple processors simultaneously.

Not that a mutex is the way to go since last time I checked you can't do 
most pthread operations (including mutex ones) in a signal or other 
interrupt handler.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About