[rdnzl-devel] attaching handler / Tablet PC ink/ stroke/ not working

[Edi Weitz]

On Thu, 22 Dec 2005 18:47:39 +0100, Edi Weitz <edi at 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>