On Mon, Feb 4, 2013 at 3:28 PM, Jonathan Fischer Friberg odyssomay@gmail.com wrote:

Hi,

It seems that abcl is currently running on the awt thread. As when I get an error, it says something along the lines

"#<THREAD "AWT-EventQueue-0" {3C6B5}>"

This has some nasty side effects, namely:

1. eval blocks the ui (until the eval has finished)
2. On error, the version 1.1.0 locks down the ui completely. That is, the ui

locks and doesn't come back.

So it would be nice if I could run abcl on it's own separate thread. Is such a thing possible?

I guess in worst case I'll have to start up a separate thread in the eval (that is, in common lisp), which I think would do what I want. I would prefer to have the whole of abcl in its' own thread though.

Actually, ABCL runs in the caller thread, so you should not make potentially long or blocking calls to it on the AWT thread (e.g. in event listeners). You should use SwingWorker if you're using Swing (see http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html) or the ExecutorService or other similar tools.

Alessio

Hi Jonathan,

On Mon, Feb 4, 2013 at 3:28 PM, Jonathan Fischer Friberg < odyssomay@gmail.com> wrote:

Hi,

It seems that abcl is currently running on the awt thread. As when I get an error, it says something along the lines

"#<THREAD "AWT-EventQueue-0" {3C6B5}>"

As Alessio said, ABCL runs in the caller's thread.

This has some nasty side effects, namely:

1. eval blocks the ui (until the eval has finished)
2. On error, the version 1.1.0 locks down the ui completely. That is, the

ui locks and doesn't come back.

That's probably because your System.in stream is bound to streams which are listening for input. The thread then only returns after ABCL has read input to know what action its user wants to take. Basically, you want to install handlers which present UI widgets to select such actions.

So it would be nice if I could run abcl on it's own separate thread. Is such a thing possible?

Absolutely, however ...

I guess in worst case I'll have to start up a separate thread in the eval (that is, in common lisp), which I think would do what I want. I would prefer to have the whole of abcl in its' own thread though.

... sometimes you want to take special precautions: while running its initialization, ABCL also initializes its dynamic environment. This environment is bound to the executing thread. Every time you create a new thread and start running Lisp code on it, you'll be given a "clean" dynamic environment. If that's ok with you, you can run as many threads on ABCL as you want. However, dynamic environments are always bound to a specific thread. There's no way to make an environment "jump from thread to thread" when you create new threads in Lisp code.

Hmm. I hope that didn't confuse things for you.

Bye,

Erik.