Am I missing something here, or is it simply not possible to call a continuation from inside another thread?
If I can't call a continuation inside another thread, is there a way to call fork() from inside mzscheme? (I've heard that 'subprocess calls fork(), but I don't know if that is really what I want or not, and I can't find any documentation on it.)
Any other suggestions as to how I could simulate fork would be appreciated.
I'll step back and ask what you're trying to do with fork. If you do a genuine fork, you'll end up with two mzscheme interpreters running, which may or may not be what you want.
You asked about doing a wait; you pass the child's pid to wait.
Returning to your original example, Mzscheme supports calling continuations from another thread, as documented at http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-6.h...
That page also describes the continuation barriers. The issue is that you can't have a new thread call a continuation in the main thread, since then you'd have two main REPL threads, which doesn't make sense.
What you need to do is run your example in yet another thread:
prints 0, 1, 12, 25, 102, 205, 822, 1645, which much larger than the expected 1, 2, 3, 4, 5, 6, 7, 8 because all the threads update the same global variable
Thanks for the information on continuations and threads. Your suggestion worked perfectly for me.
And if you have to know, I am trying to port a program entered in the 5th annual Obfuscated Perl Contest (http://perl.plover.com/obfuscated/). It was originally implemented using fork(), but I was experimenting with using continuations and threads just to see if it would work.
I took a look at the Perl program. Just a warning: Arc doesn't have real pipes, so if you try to synchronize on pipes like the Arc program, you're in for trouble. Also, if you implement real forks and fork 32 mzscheme interpreters in parallel, you better have a bigger computer than mine :-)
I do have one question about loading libc. Since the system doesn't automatically find libc.so for you, you need to name the path explicitly. What worked for me was
The underlying foreign implementation is looking for the
library. The problem is that /usr/lib/libc.so is not the
library and dlopen() does not know how to handle this.
A better alternative with mzscheme's foreign interface is
to use `#f' for the library -- that treats the mzscheme
binary as the library to open (which includes the usual
libc stuff.)
Also, I think I need to use wait() to wait for a child process to terminate, but I am somewhat at a loss as to how to accomplish this, since the manual says it takes an int pointer... Again, any help would be appreciate.
Also, in your malloc() example, don't you have to explicitly free the memory afterwards? MzScheme's GC doesn't deal with memory explicitly allocated from C, does it? (I know the example itself uses only a tiny amount of memory, but still...)
Yes and no. I think mzscheme's GC can handle it without explicitly calling free at the right time, but you have to register a "finalizer" function to do so. That function will be called when the GC collects the object.
It does not know the size of malloced objects however, so be careful (no pb there, but if you allocate something very big, mzscheme will only see a new reference and will not necessarily call GC when you will actually lack memory).