[plt-scheme] Interaction between Dr. Scheme and foreign libraries

At Sat, 19 Nov 2005 14:07:59 -0500, Ittai Balaban wrote:
> I've run into the following situation, trying to use DrScheme with a
> file requiring a module that does initialization of a foreign library:
> When you hit 'run' in DrScheme, the interaction environment is
> completely "rebooted", i.e. a module loaded before the 'run' will be
> reloaded post-run. However, while scheme is effectively in a fresh
> state, this is not true for the foreign library, leading to it being
> initialized again and again on subsequent 'run's.

As Robby and Eli say, our normal model is that the foreign library
should be shut down when the Scheme program is shut down by DrScheme.
The library shutdown would be implemented by attaching a shutdown
function (which the foreign library would have to provide) to the
current custodian.

Eli's suggestion --- adding an unload to the FFI system --- makes
sense if the library's shutdown function is implemented in terms of
unloading the library. That seems likely for Windows and unlikely for
other platforms.

> Any suggestions (other than requiring the user to explicitly initialize
> foreign libraries)? Specifically, I have some module code that I would
> like to run *once* per DrScheme process.

If the foreign library doesn't provide a shutdown operation, or if you
really want the library state to persist across runs, then I can only
explain why I don't have a good answer. :)

It's analogous to having a device driver that is shared across
processes in an OS. (In this analogy, DrScheme is the OS, and different
clicks of the "Run" button start different processes.) In much the same
way that you could add a device driver to an OS, you could add a tool
to DrScheme to manage the library across program runs.

I can see why you wouldn't want to create a DrScheme tool, just like
you probably wouldn't want to make your users install a device driver.
If I understand the problem, though, the library is acting like a new
device from DrScheme's perspective, so a tool would be the
general-purpose solution. Depending on specific details of the library,
any number of other hacks might work.

In any case, a tool would be specific to DrScheme. MzScheme, at its
lower level of organization, doesn't really have a concept that's like
a device driver. (Maybe it should.)

Matthew