On Thu, Mar 18, 2010 at 11:29 PM, Graham Douglas
Hi Luigi
That is very cool work. At present, it is a bit beyond my fuzzy skills, but I will dfinitely keep a copy of your slides for future reference as I slowly.... get a bit more familiar with LuaTeX etc.
Thanks for sharing that.
We have 2 ways to interface with an external program 1) \write18 . In this way (lua/pdf)tex runs the program using the OS, ie something like os.cmd, . and a completely new task is created. We have a clear separation between luatex process an program process and usually if the program process aborts luatex can manage this situation nicely. It's robust but it's also slow, as the case for mkii with metapost shown; 2) dynamic loading of a library, a *so or a *dll. In this case there is not another process to start: luatex is extended with this new library at runtime. So, if a the library aborts while you are calling a function, then luatex aborts --- and you can't manage this situation. Now, if your library declare a symbol that is also defined by luatex or if you library has a function that load another library at runtime and this one has a symbol that is also defined by luatex , then you have a symbol collision and hence with high probability a segfault . Trace the symbol collision can be very hard, so actually it's less robust than 1) (remember that *tex must be portable to many SO, so robustness is really important). Of course there is a benefict: the gain in speed can be 1000 (one thousand times) and if I remember well, Hans reported 10000 with mplib (which is included in luatex at compilation time ). -- luigi