[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: felix
Subject: Re: [Chicken-users] RE: Win32/cygwin dynamic loading
Date: Mon, 24 Feb 2003 23:48:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

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

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,  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, 
  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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]