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

Re: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
David M. Lloyd
August 22, 2001 06:30
Re: [PATCH] Adding callbacks to the core
Message ID:
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.

When at least one callback is enabled, there are three comparisons per
opcode instead of one.  If Perl receives a signal while callbacks are
enabled, there are still three comparisons per opcode.

So you see, callbacks (should) only have a significant impact when you use

> >> Under ithreads, the callbacks are by interpreter, hence there is no
> >> need to lock the list of callbacks.
> >
> > The mutex is not for the sake of ithreads OR 5005threads.  The mutex is
> > there so an XS module can launch a thread and have a clean way to
> > resynchronize.  If it were possible, I'd use the mutex even if Perl wasn't
> > compiled to use threads.
> 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.

> 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.

So you see, as long as you don't *free* a callback from a callback or from
any thread but the interpreter's main thread, there is no problem.  (In
fact, I am adding this bit of info to the apidoc for free_callback.)

> However I do like this idea. I think I will make POSIX aio available
> to perl after ithreads start working :)

Cool :-)

- D


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