I am a bit confused when reading about, and experimenting with, the
WIRE package in CMU Common Lisp (release 17f).
The function wire:create-request-server of two arguments is supposed
to return a wire structure; however it actually returns something of
type wire::request-server.
The function returns immediately, so this means "the main thread"
keeps running.
When a client from the outside connects to the port, the function
passed as the second argument to wire:create-request-server is
invoked. This appears to be "another thread", separate from the first
one?
In this second thread I really get access to something that is a wire
in the sense of wire:wire-p. The wire can be used for reading and
writing, using wire:wire-get-byte and wire:wire-output-byte.
The two threads seem to exclude each other from simultaneous
execution. If I put the main thread in a sleep-printout loop it seems
to exclude the port-watching thread from executing. On the other hand,
if I let the main thread go to top level and wait for terminal input,
the port-watching thread actually does its job. Once it has started
to, it will block the main thread from executing the top level
read-eval-print loop.
What I would really like is some controlled way of waiting for the
wire transaction to finish, and then continue in the main
thread. Being able to set a timeout for the case that noone connects
to the port would be a bonus. Is it possible to do any of this?
Rabbe Fogelholm, Ellemtel, Stockholm, Sweden
www.pcs.ellemtel.net/~eubrafo
In article <·························@news1.telia.com>,
···············@ellemtel.se (Rabbe Fogelholm) writes:
> I am a bit confused when reading about, and experimenting with, the
> WIRE package in CMU Common Lisp (release 17f).
>
> The two threads seem to exclude each other from simultaneous
> execution. If I put the main thread in a sleep-printout loop it seems
> to exclude the port-watching thread from executing. On the other hand,
> if I let the main thread go to top level and wait for terminal input,
> the port-watching thread actually does its job. Once it has started
> to, it will block the main thread from executing the top level
> read-eval-print loop.
CMUCL doesn't have threads. (At least not the one
you're probably using. Some of the newer,
experimental versions for PCs have some thread
capability.) The WIRE stuff is implemented
essentially as a Unix select() call on all of the
open file desricptors that have been registered with
it. (That includes the top level loop.) As a result,
the illusion of multiple threads only works as long
as all "threads" cooperate by returning to the top
level on a regular basis.
Mike McDonald
·······@mikemac.com