Re: [Chicken-users] RE: Win32/cygwin dynamic loading

[felix]

Jonah Beckford wrote:
> Oh yeah, just forget to make something explicit ... this dynamic loading
> was just a proof of concept.  The goal was to find a set of principles
> to support dynamic loading on the broadest of platforms (basically, code
> normalization).  Now that I think we have most of the principles
> (outlined below), I would still use __declspec(dllimport) for Win32
> (which should work if the "principles" are followed) etc. and only use
> the "primitive" shared loading technique for trully primitive platforms
> and maybe for thread safety.

Agreed. I appreciate the work you've put into this, and I'm sure
we will be able to add at least part of your changes into the core
system. But I have to add a few comments, since, to be frank, I'm not
completely happy with it:

- The performance impact we have with the C_shlib device is pretty hard.
  In fact a little bit to heavy for me. Thread-safety is definitely an
  issue, but I'm not eager to reduce overall performance more than
  absolutely necessary. If I understand the machinery you devised correctly,
  this is not needed on platforms that have some form of dynamic loading.
  Specifically: win32, cygwin, mingw32. That's fine with me. But supporting
  anything more than windows and most unices is, strictly speaking,
  not worth the effort.

> - A one-to-one mapping between units and shared libraries

Hm. I understand, but I like to keep the number of libraries small.
(at least for the base system).

> - Runtime, as opposed to link-time, resolution of units (using
> load/load-library)

Ok. Yet, (again): the base system should work in a static-linking
environment, too.

> - The call to (load "xxx") for a dynamic module must not use any prefix
> or suffix (like prefix=lib, suffix=.so).  In fact, it will be difficult
> to support any paths like (load "/usr/local/chicken/srfi-13") ... not
> only is that system-dependent, the parsing routine used to search for
> alternatives like /usr/local/chicken/cygsrfi-13-0.dll would be quite
> difficult.  The dynamic modules must be locatable with a standard
> mechanism (maybe search the current directory, followed by the
> system-dependant library search path, followed by CHICKEN_HOME).  This
> also means they must be installable with a standard mechanism (I like
> William Annis' suggestion of something like Python's Distutils or Perl's
> Makefile.PL; I haven't looked at "eggs" yet, but I have a suspicion they
> are for pure Scheme code).

The extension-mechanism (the "eggs") is actually intended exactly for this
problem: having a standard way of loading compiled code dynamically.
That `load' uses proper pathnames is Ok, IMHO. `require' (and
`require-for-syntax') uses the pathnames found in the extension
registry and (if not found there) in the current path and the include path.
It's really just a wrapper for `load', which constructs some standard
pathnames and searches for something suitable for loading.

> - Specification of -static or -shared when using chicken-config (so it
> can pick the right libruntime) and change the compiler -D defines.  This
> also means the chicken-config, or its replacement, must be useable on
> all platforms.

On windows we can also use `csc.bat'.

I propose a somewhat different approach. It probably has it's own set of
problems, but bear with me:

1) The compiler emits a `C_main_entry_point' for non-units (or main-units,
  i.e. code that doesn't have a `unit' declaration).
2) C_main_entry_point expands into a `main()' (or `WinMain()' if C_WINDOWS_GUI
  is defined) that calls `CHICKEN_main()' with the command-line arguments and
  `C_toplevel'. If this file is compiled with -DC_SHARED or -DC_EMBEDDED, 
C_main_entry_point
  is empty.
3) CHICKEN_main() does CHICKEN_initialize() and passes the toplevel pointer.
  This will handle the circular dependency from the main code to runtime.c
  and back to C_toplevel (since C_toplevel is passed directly).
  As a side effect we get rid of libembedded-chicken.
4) So we have the following possible configurations:
   - normal main unit (has C_main_entry_point -> main/WinMain)
   - dynamically loadable main unit (has C_toplevel and nothing else)
   - library unit (linked statically/dynamically/implicit/explicit)
     (has no special handling - just the `C_..._toplevel()' as usual)
5) Add the declspec cruft for Win32, with the usual macro hackery for
   switching between dllimport/dllexport (I still don't know how cygwin
   handles this - can someone explain this to me? Wasn't there something
   like dlltool?). Since we have no circular dependencies anymore,
   this should work (or not?)
6) Change `chicken-config' and `csc[.bat]' to handle all the options.

It doesn't address all issues yet, but it's a careful start at getting
into the (IMHO) right direction.

What do you think?


cheers,
felix