Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
A session is a group of threads with one of them being the foreground threa=
i.e. the one that is regarded as the owner of the input streams: *debug-io*=
* a session can be terminated which terminates all threads in it
* threads that belong to the same session "arbitrate between themselves for=
the user's attention"
* by default threads share the input streams (possibly even if they are in=
* while sbcl's debugger and repl are aware of threads, portable code that j=
waits for an input will not honour the get-foreground, release-foreground=20
* if a thread has some private means of doing io and rebinds the io streams=
then the debugger (and other interactive things) in that thread shouldn't=20
get-foreground because in this case it only serves as a mutex for unrelated=
Under unix session handling if a background process reads from the controll=
terminal it gets a sigttin and stops. As far as I can tell allegro has=20
Create a stream class that throws an error on read if it's not the foregrou=
thread and provides a retry restart. On that error the debugger is invoked=
and it waits until it's in the foreground just as it does today.
=46urthermore with-new-session should probably in some sense "detach" itsel=
from the terminal like setsid() does.
I think it is a sound approach that mimics the unixy way very closely, but =
not in a hurry to implement it.