Re: Dynamic loading progress

["Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>]

Daniel Colascione writes:
 > On 09/13/2015 01:31 PM, Stefan Monnier wrote:

 > >> It's not possible to skip frames in module code using longjmp, so
 > > 
 > > Why not?
 > 
 > Because most C code isn't expecting to be unwound. Forcing non-local
 > flow control on module code is completely unacceptable.

"Completely unacceptable" is nonsense.  Module code needs to be
written the same way any other Emacs code is written, using various
unwind-protect constructs.  If the module wraps external code that
has state that persists past the unwinding, you also need to use the
underlying code's own "unwind protection".

For example, XEmacs has had a PostgreSQL interface module based on
libpq for about 15 years, and nobody has ever reported any trouble of
that kind.  The Lisp API provides transactions, and the unwind code in
XEmacs knows to rollback if there's a pending transaction on nonlocal
exit.  Sure, all of XEmacs, PostgreSQL, and the module have had bugs
in them -- but nobody has blamed an XEmacs crash or database
corruption on that module yet.  OK, there may not be all that much
experience, but at least two people used it heavily in mission
critical roles for 5 years (they were supporting a Fortune 500
company's trouble ticket database).  I acknowledge that the risk is
probably somewhat greater than if the code were built-in to XEmacs.

Sure, it's likely that module programmers will not be as well-versed
in Emacs unwinding as Emacs core developers are, but by that same
token they're probably quite well-versed in the target code's
features.  Overall, modules are likely to be less stable than core
Emacs, but presumably that's a tradeoff that module users are willing
to accept.

And I'm sure that there's non-robust code in libraries out there that
will be totally horked on a non-local exit.  But AFAICS you have the
same problem there if you link statically or at Emacs initialization
-- that code just shouldn't be linked into Emacs period.