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

Re: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
From:
Arthur Bergman
Date:
August 22, 2001 08:14
Subject:
Re: [PATCH] Adding callbacks to the core
Message ID:
B7A998D9.3409%arthur@contiller.se
01-08-22 16.51, skrev David M. Lloyd på dmlloyd@tds.net följande:

> I am anything but an expert on this sort of thing, but I figured I could
> depend on ordering here because even if the CPU does odd things like
> threading, the CPU still has to depend on the logical order of the
> operations I'm performing; for instance no matter how the CPU threads, it
> wouldn't make logical sense to do a comparison with a variable before or
> during an assignment that precedes the comparision.
> 
> However, looking at this code yet again, I suspect there may be a race at
> the beginning of the for loop.  I'll have to look at it some more.  Sigh.

There is a race condition. If the next callback gets disabled it breaks.

I would suggest removing the distinction between create/enable and
disable/free, if a handler needs to reliably disable itself it can use it's
own mutex.

To do one shot things I suggest we add psuedo signals instead. Possibly
declared at compile time.

>> 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.
> 
> This loop is not run from within a signal/interrupt handler... it is
> called from Perl_runops_*.
> 
> I may have to go to mutexes after all... :-(



-- 
Arthur




Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About