On Thu, 22 Dec 2005 18:47:39 +0100, Edi Weitz edi@agharta.de wrote:
I forgot to mention: My guess is that this doesn't work because of threading issues - .NET is trying to call into Lisp from a thread which wasn't created by Lisp. [...] I'm not familiar enough with AllegroCL but maybe it's similar there.
Hmm, seems that it's slightly more complicated in this case. I got a copy of AllegroCL 8.0 for Windows today and played around with it a bit. Still no solution, unfortunately, but here are some more data points:
1. RDNZL seems to work fine with AllegroCL 8.0. I had already checked with the beta, so no surprise.
2. The problem with the "Microsoft.Ink" library remains the same, though.
3. I rummaged around in the AllegroCL docs and found the following:
"A note on calling into Lisp from threads started by foreign code
[...]
In an :os-threads Allegro CL, however, it is legitimate for a thread started outside Lisp to call into Lisp via any foreign-callable function. Some extra work has to be done to create a Lisp process to represent that thread within the lisp world. That extra work is performed by a 'customs agent' process that is started by a call to START-CUSTOMS. See the documentation for that function for details."
Aha! So we just have to call START-CUSTOMS and everything works? No, unfortunately not.
4. The reference entry for START-CUSTOMS says that the function is deprecated, so the paragraph from above is bogus. Nowadays, START-CUSTOM just calls START-SCHEDULER and (again, according to the docs) this is actually never necessary because starting a process will call this function implicitely.
5. So, back to square one. But I thought, hey, what will happen if I start the function DEMO[1] not from the REPL but from a thread?
(mp:process-run-function "demo" #'demo)
The problem is still the same but MP:PROCESS-RUN-FUNCTION does /not/ return until I close the .NET window. So, /something/ is blocking there because the function usually returns immediately.
As I said, still no cigar. But maybe someone more familiar with AllegroCL's MP implementation knows what to make of this.
Cheers, Edi.
[1] see http://common-lisp.net/pipermail/rdnzl-devel/2005-December/000044.html