|
|
 Up |
|
|
  |
Author: DavidMDavidM Date: Jul 2, 2008 19:22
Hi all,
I've been working on an 'extension library' loader for FICL, which I plan
to port to other forths.
This loader is a bit like gForth's 'fflib' - it allows one to load shared
C libraries (.so files on nix, .dll files on windows), extract C
functions, and invoke them with correct arguments - all from within Forth
code.
But on considering the task of porting this loader to other forths, an
issue came to mind...
Many or most popular forths are 'image-based'. In other words, the forth
words are compiled into an image file which is loaded on system startup,
and can be saved and restarted as more words are defined.
Here's the problem - if any dynamic library loading is performed outside
of word definitions - in other words, if a forth source file performs
library loading in interpret mode (as opposed to runtime, when words are
invoked), then there will be forth words in the system containing live
pointers to C entities - library handles, C function pointers, pointers
to objects returned by C functions etc.
|
| Show full article (2.26Kb) |
|
| | 4 Comments |
|
|
Author: Alex McDonaldAlex McDonald Date: Jul 3, 2008 00:59
On Jul 3, 3:22 am, DavidM nowhere.com> wrote:> Hi all,
>
> I've been working on an 'extension library' loader for FICL, which I plan
> to port to other forths.
>
> This loader is a bit like gForth's 'fflib' - it allows one to load shared
> C libraries (.so files on nix, .dll files on windows), extract C
> functions, and invoke them with correct arguments - all from within Forth
> code.
>
> But on considering the task of porting this loader to other forths, an
> issue came to mind...
>
> Many or most popular forths are 'image-based'. In other words, the forth
> words are compiled into an image file which is loaded on system startup,
> and can be saved and restarted as more words are defined.
>
> Here's the problem - if any dynamic library loading is performed outside
> of word definitions - in other words, if a forth source file performs ...
|
| Show full article (3.98Kb) |
|
| | no comments |
|
|
Author: Bruce McFarlingBruce McFarling Date: Jul 3, 2008 03:50
On Jul 2, 10:22 pm, DavidM nowhere.com> wrote:
> Many or most popular forths are 'image-based'. In other words, the forth
> words are compiled into an image file which is loaded on system startup,
> and can be saved and restarted as more words are defined.
> Here's the problem - if any dynamic library loading is performed outside
> of word definitions - in other words, if a forth source file performs
> library loading in interpret mode (as opposed to runtime, when words are
> invoked), then there will be forth words in the system containing live
> pointers to C entities - library handles, C function pointers, pointers
> to objects returned by C functions etc.
> Such words will work perfectly in the current session, but I can easily
> see that if one saves the 'image', then reloads it into a new session,
> then these words can easily end up with dangling pointers - pointing off
> into the boondocks - and the words will throw one into a sea of segfaults.
> Has anyone put any thought into this problem?
|
| Show full article (1.74Kb) |
| no comments |
|
|
Author: George HubertGeorge Hubert Date: Jul 3, 2008 03:53
On Jul 3, 8:59 am, Alex McDonald rivadpm.com> wrote:> On Jul 3, 3:22 am, DavidM nowhere.com> wrote:
>
>
>
>
>>> Hi all,
>
>> I've been working on an 'extension library' loader for FICL, which I plan
>> to port to other forths.
>
>> This loader is a bit like gForth's 'fflib' - it allows one to load shared
>> C libraries (.so files on nix, .dll files on windows), extract C
>> functions, and invoke them with correct arguments - all from within Forth
>> code.
>
>> But on considering the task of porting this loader to other forths, an
>> issue came to mind...
> ...
|
| Show full article (4.50Kb) |
| no comments |
|
|
|
|
|
Author: George HubertGeorge Hubert Date: Jul 3, 2008 03:57
On Jul 3, 11:53 am, George Hubert yahoo.co.uk> wrote:>
> It was always that way.
^^^
Oops! Should be wasn't.
George Hubert
|
| |
| no comments |
|
|
