Re: !ERR and MPFIT

[Craig Markwardt <craigmnet(at)cow.physics.wisc.edu>]

m218003@modell3.dkrz.de (Martin Schultz) writes:
> 
> In article <MPG.129be687cb5374e598996c@news.frii.com>,
> 	davidf@dfanning.com (David Fanning) writes:
> > Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> > 
> >> now I am leaning toward the common-block approach.  Sorry David.
> > 
> > Oh, I like it. And to tell you the truth, this might
> > be the *perfect* situation for a common block. Just
> > don't be putting 'em in a widget program! :-)
> > 
> 
> Now, what happens if you have two or three widgets open each of which 
> is calling MPFIT through some means. Would a common block still work?
> And please think once more: may not be possible now, but I am quite certain
> that RSI will one day support SMP, so it could indeed happen that those
> calls to MPFIT were executed simultaneously! I'd go for the keyword - this
> is clean.

I totally understand what you are saying.  Keywords make everything
clean.  But consider the following function:

  function myfunc, x, p
    ...
  end

It doesn't accept keywords.  Now, if MPFIT tries to call this function
with an ERROR keyword, everything crashes.  I could try CATCHing such
an error, and retrying the function call with without the ERROR
keyword, but then what's more ugly?  By the way, I've changed the
implementation of MPFITFUN to use common blocks instead of pointers
(handles really), and it's become much more clean and easy to read
now.

The common block implementation has its virtues.  It's totally
optional.  It wouldn't collide with any other system error variables.
It's certainly better than my current use of !ERR.  And, currently,
it's guaranteed that only one session of MPFIT can be running
simultaneously.

I am sure that when (if!) RSI implements multithreaded IDL, almost
everything is going to crash.  Not just MPFIT.  Consider every program
that uses common blocks, *especially* the thousands of IDL library
scripts, assumes a single thread of execution.  RSI will have to
implement some kind of new functionality to keep things working and I
for one will depend on that! :-)

Craig

-- 
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
--------------------------------------------------------------------------