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

Re: SV: Implementing Callbacks (Was: RE: [PATCH] Adding callbacksto thecore)

Thread Previous | Thread Next
David M. Lloyd
August 22, 2001 13:46
Re: SV: Implementing Callbacks (Was: RE: [PATCH] Adding callbacksto thecore)
Message ID:
On Wed, 22 Aug 2001, Arthur Bergman wrote:

> > On Wed, 22 Aug 2001, Arthur Bergman wrote:
> >
> > > I do not know how many times I have to say this, the above code is
> > > faulty, if the next callback gets disabled.
> >
> > Right, I should have said this:
> >
> >   Disable a previously registered callback.  If the callback is not
> >   enabled, does nothing.  A callback may disable itself, but otherwise
> >   this function should only be called outside of a callback in the main
> >   thread.
> And then we don't need the mutex.

We *do* need the mutex, because otherwise the value of PL_callback_head
could change in the time between the comparison and the assignment.
After all, a thread can enable a callback at any time.  In any case, the
cost of the mutex AND the assignment is negligable because it is only used
*one opcode after* a signal has been handled.  Which is infrequent.  It's
the operation that occurs with every opcode (that is, three comparisons,
and the for loop, but NO mutexes) that I'm more worried about. In fact, if
your Perl script never gets a signal, and has one callback that is enabled
then later disabled, the mutex is only exercised two times in the entire
life of the program.  Add a signal, and it's three times.  Not a huge
impact, right?

> If we have an array of all enabled callbacks then we can just go over
> it and call them. Since we have already established that optimization
> should be on calling the cost of insertion or removal can be payed
> for.

OK, I'll try that and see if it's faster.  But there's a couple problems.

1. Not async-safe.  You may have to malloc() to grow the array, and that's
probably not a good thing to do in async code.  Granted, being async safe
is more of a bonus than a goal.

2. Still need a mutex.  Only one thing should be inserting at a time
because the array may grow, and therefore its position might change, which
is not atomic AFAIK.

> > But I think the issue is not that it's a linked list.  I think that the
> > reason it's slow is the three comparisons.
> I think the reason is the linked list and the assignment.

I'll revise: the three comparisons plus the various assignments and
comparisons associated with the for loop.

> > Solution?  I think that I have to come up with some way to combine signals
> > and callbacks, so that we get the speed that we have today (one comparison
> > no matter what) and yet still be able to pass data from an asynchronous
> > C function to the callback, or from a seperate thread to the callback.
> Ah, but to do this we need a mutex, can't the callback fetch the data
> from somewhere else?
> Asynchronous C function notifies callback should be run and stores
> data at known position, unlocks mutex. Callback locks mutex and gets
> the data from known position-

Maybe, but it looks like I would need a mutex anyway.

- D


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