GL> and then there's
GL> "embedded" as in "must achieve a frame rate of 30 hz".
Where
"30 Hz" is a variable,
and
"must" may be of varying strength / harm -
* otherwise the screen refresh will be skipped jerky, or only partial
ugly;
...
* otherwise "Flight Law" control loop time is violated and positive
control
of the airframe is no longer guaranteed
> expensive
Yes. longjmp was once not only less C code but far far quicker to unwind
a deep stack than the standard
return(-1) if rc < 0; # lather rinse repeat
in old C on old slow hardware without optimized stack instructions. The
return()'s register swizzling is far cheaper on today's hardware which
has support for such, so that is less true today. Doing an exception
throw in OO C++ or Java or even Perl requires MUCH MORE *implicit* work
as the exception propagates through the call stack checking at each
frame for potential catches and potential destructors for on-stack
objects being freed.
An actual longjmp in C++ would cause any off-stack resources held by
over-jumped stack to leak.
Exceptions are perhaps the least pernicious form of COME FROM flow
control, but that is damning with faint praise.
COME FROM are as a class generally even more evil than the GO TO.
However, TRY{THROW}CATCH{} exceptions (including eval{die} and even
longjmp ) are less egregious action-at-a-distance COME FROM than their
older siblings the SIGNAL handlers like $SIG{FPE} and PL/I ON
CONDITIONs. At least die or THOW provides a syntactic marker at the
spot that the COME FROM might come from, whereas any arithmetic
expression is a possible raiser of $SIG{FPE}, and any opcode may be hit
by an external $SIG{KILL} or $SIG{INT}. And the CATCH is conveniently at
the point of last call, not buried somewhere in boilerplate like
$SIG{KILL}= \sub {state $zombie; $zombie++};
Such action at a distance is best used only as the emergency escape
hatch they were designed for. SIG is lean, as it needs to be at
Interrupt level, and it can throw a die, which can be as expensive as it
needs to be to free resources as it winds up the stack, since it is only
called exceptionally.
If one actually needs non-emergency action-at-a-distance (not common,
usually a refactoring is what is needed, possibly into a process
pipeline), Co-Routine call&yield is often an appropriate, controlled,
and efficient mechanism
[Eg http://search.cpan.org/~mlehmann/Coro-5.21/Coro/Intro.pod ]
A good reason for such is when a parse-transform-generate pipeline
needs to be optimized as thread-to-thread in-memory pass instead of
slower IPC, eg when doing a Jackson Program Design inversion of a parser
to create the generator. (although XSLT or XProc may be better than
bespoke implementation of a complex XML2XML transform, someone has to
build the XSLT XProc engines, and sometimes source or target doc isn't
in the *ML family ... .)
Another example is http://search.cpan.org/dist/Perl6-GatherTake/
(EXPERIMENTAL!) which uses Coro to implement Perl6's gather-take
keywords to build lazy list generators.
And PLACK/PSGI use Coro
http://deps.cpantesters.org/depended-on-by.pl?dist=Coro-5.21
Bill @ $DayJob
Not an official statement of anyone
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
