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

Re: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
Arthur Bergman
August 22, 2001 07:03
Re: [PATCH] Adding callbacks to the core
Message ID:
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.

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

Why 4 comparions when no callback and 3 when callback?

I look forward to read the updated patch.
> So you see, callbacks (should) only have a significant impact when you use
> them.
>>>> 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.

Just compile with useithreads.

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

But if the callback in next gets disabled while cur is will be executed and
then no more will be exeucted which is wrong.

> 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