From: Jeff Dalton
Subject: Re: select in Lisp (Re: The New Lisp Machine)
Date:
Message-ID: <8820@skye.ed.ac.uk>
In article <···················@passy.ilog.fr> ·····@passy.ilog.fr (Harley Davis) writes:
>
>
>In article <···········@cix.compulink.co.uk> ············@cix.compulink.co.uk (Cyber Surfer) writes:
>
> (Jeff Dalton) writes:
>
> > Wait a minute. That fact that something is _now_ a feature
> > of Unix is no reason to say it _cannot_ be part of a language.
> > That simply doesn't follow.
>
> I've never used Unix, and I don't expect to, the way the market
> looks just now. I have no experience with Unix, but plenty
> with Microsoft Windows. No C compiler for this platform uses
> SELECT.
It's a library function. The compiler doesn't have to know
anything about it.
> > In any case, select is a well-defined operation that could be
> > included in a language. A basic select is no more suspect that
> > LISTEN or READ-CHAR-NO-HANG.
>
> Since I don't know what it does, I can't be sure SELECT won't
> ever be supported under Microsoft Windows 3.x,
SELECT doesn't have to be supplied directly by the operating system or
the C compiler; it might be implemented some other way. You seem to
think that because it's built into Unix (in a sense) that it has to be
built into some compiler or OS before it could be used in Lisp. But
that isn't so; it might be implemented in some other way.
> however, since
> I/O support is largely compiler dependant for this platform,
> as it only provides very crude functions thru to the DOS layer,
And this kind of platform is winning over Unix? There's a lesson
for us in there somewhere, no doubt.
> it's a vendor problem. Someone else will have to comment on
> this, as I don't do that kind of I/O under this platform.
>
> My point is that the name is unknown to me, and that's because
> it's not available in any compiler I have access to. My 1988 copy
> of K&R doesn't mention it. Could you please explain SELECT in
> terms of the WinNT API? Then I'd know what we're talking about.
>
>SELECT basically implements one cycle of the wait-for-message /
>process-message loop which is fundamental to Windows programming.
>Given a set of input channels to an application, it tells you which of
>them have messages waiting to be processed.
A little while back, I described how to implement a version of SELECT
by polling using LISTEN. Barmar (I think) even posted code. ...
Yes, here it is:
----------------------------------------------------------------------
Common Lisp doesn't have any support for non-blocking output, so I'll give
a simple solution that works only for input streams. Unfortunately, it
uses polling.
(defun input-select (streams timeout)
"Wait until any of STREAMS has input available or TIMEOUT seconds elapse.
Returns the list of ready streams or () to indicate a timeout."
(loop with end-time = (+ (get-universal-time) timeout)
when (>= (get-universal-time) end-time)
return '()
when (loop for stream in streams
when (listen stream)
collect stream)
return it
;; don't chew up CPU cycles
do (sleep 1)))
This isn't how I'd do it if I were writing non-portable code for a
Symbolics system; in that case I'd use PROCESS-WAIT or something like that.
----------------------------------------------------------------------
-- jd