Loading Shared Libraries
ardeujho
ardeujho at cd.pn
Fri Mar 14 18:03:47 UTC 2014
In 'objects/applications/serverDemo' there is an example of loading a
shared library and using it from Self. The code has bitrot. The makefile
no longer works and the binaries in there are old. I've put a patch that
gets this working on Mac OS X at:
<http://pastebin.ca/2662490>
Also required is a fix to a core file:
<http://pastebin.ca/2662493>
Once that patch is applied you'll need to reload that file into your
image (or build a new one). That patch fixes an issue where Self
prepends an underscore to foreign function symbol names before lookup.
I haven't done a git pull request yet as I want to get this working on
Linux as well first but I'm traveling for a couple of days and won't get
around to that. I'm mentioning it here to get feedback before I add
other platform support.
To do the demo, after doing a Mac OS X build of Self, change to the
'objects/applications/serverDemo' directory and run 'make'. This will
build the shared library and C client program.
To run, start Self from the 'objects' directory:
$ cd objects
$ ../vm/Self.app/Contents/MacOS/Self -s myimage.snap
Then load the server.self file:
Self> bootstrap read: 'server' From: 'applications/serverDemo'.
Run the server:
Self> (message copy receiver: serverDemo server Selector: start) fork.
This will block as it runs a C 'accept' call exposed by the shared
library. In another terminal window run the client to send Self comands
to the server:
$ ./toself "'hello' print"
$ ./toself _Quit
Should this demo be kept the same? It uses the lower level Glue
functions directly? Or would it be better to modify it to use
primitiveMaker? Or maybe do a 'serverDemo2' that uses primitiveMaker to
compare the approaches?
Is there a better way to 'fork' the server? The example given in a
server.self comment uses a block but this fails due to non-LIFO blocks.
More information about the Self-interest
mailing list