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

Re: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
August 22, 2001 08:26
Subject:
Re: [PATCH] Adding callbacks to the core
Message ID:
5.1.0.14.0.20010822111507.08c0ed18@tuatha.sidhe.org
At 09:51 AM 8/22/2001 -0500, David M. Lloyd wrote:
>On Wed, 22 Aug 2001, Dan Sugalski wrote:
>
> > > > 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.
>
>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.

Sure, and that's true more or less, for single CPU systems. It is not at 
all true for multi-cpu systems. Neither is it necessarily true for 
optimized code, since you run the risk of having memory updated after it's 
been loaded into registers and such if something async comes along and 
changes things in memory.

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

Sure, but the mutex is protecting *something*, which means that potentially 
other code paths will be aquiring it. (If the only thing using the mutex is 
runops, I'm not sure what the point is) If those paths are in, say, a 
signal handler or other interrupt-tine code, you can't use any of the 
pthreads routines to speak of, certainly not the mutex stuff.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


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