Subject: Re: Unification
From: (Rob Warnock)
Date: 25 Jun 2001 02:14:53 GMT
Newsgroups: comp.lang.lisp
Message-ID: <9h66qt$j5hca$>
Bulent Murtezaoglu  <> wrote:
| "RW" == Rob Warnock <> 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:

	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()":

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 Warnock, 31-2-510		<>
SGI Network Engineering		<> [until 8/15]
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: and aren't for humans ]