Bulent Murtezaoglu <bm@acm.org> wrote:
+---------------
| "RW" == Rob Warnock <rpw3@rigden.engr.sgi.com> writes:
| RW> By "select() properly interact with threading", I mean that if
| RW> one thread in your Lisp program does a blocking read on a
| RW> terminal and another does a blocking read on a socket, "the
| RW> right thing" happens (that is, the correct thread immediately
| RW> wakes and completes the read) regardless of which device
| RW> produces data first. [...]
|
| Hmm. Do MP lisps handle this at all?
+---------------
Dunno 'bout multiprocessor (which is what I assume "MP" means), but
some multithreaded systems do. [I said "systems", rather than "Lisps",
for soon-to-be-obvious reasons...]
+---------------
| I'd assumed they were using some user space infra-structure so if
| a syscall blocks, everything blocks (mod signal/syscall issues).
| Do you mean some magic (neat programming) happens and lisp stream
| functions get funneled through a select loop and non-blocking IO
| syscalls?
+---------------
Yes, MzScheme threads do precisely that. If a read in one thread would
block, the read is deferred, the thread is de-scheduled, and the low-level
file descriptor is added to the bit-mask of a system-maintained common
"select()" call that's done when there's nothing else runnable.
+---------------
| But if you actually have that, waking up the right thread should be
| no problem. I assume I am missing something?
+---------------
Waking up the right thread for system-defined I/O is no problem, but
remember we were talking about "bolting on" socket I/O with an FFI.
My question was whether each multithreaded system provided a clean
way for such FFI-added code to participate in the "select()" magic.
For example, MzScheme provides to extension programmers a
"scheme_block_until()" function:
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/insidemz/node29.htm>
...
This procedure takes two functions: a polling function that
tests whether the blocking operation can be completed, and a
prepare-to-sleep function that sets bits in fd_sets when MzScheme
decides to sleep (because all MzScheme threads are blocked).
And for callbacks going the other way, it has "scheme_wakeup_on_input()":
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/insidemz/node31.htm>
I would hope that all the Common Lisps that have threads have something
similar. The point I was trying to make to the OP was that to add something
like sockets, you *can't* just "bolt it on" with an FFI and expect it
to "play nice" with the rest of the system unless you find out what
system-dependent thread and non-blocking I/O features exist and then
make your FFI-added code work with them.
-Rob
-----
Rob Warnock, 31-2-510 <rpw3@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]