[squeak-dev] [ANN] The Squeak Shell
David T. Lewis
lewis at mail.msen.com
Tue Jul 12 02:53:07 UTC 2016
On Mon, Jul 11, 2016 at 04:44:47PM +0200, Tobias Pape wrote:
> On 11.07.2016, at 15:18, Tony Garnock-Jones <tonyg at ccs.neu.edu> wrote:
> > On 2016-07-11 6:44 AM, marcel.taeumel wrote:
> >> I did try to use stdin and stdout, but it is blocking for an
> >> empty input.
> > This sounds like the problems I was having reading from /dev/... files.
> > Perhaps the OSProcess-nonblocking-style solution I was using there could
> > also work for this case:
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-June/190051.html
> > Regards,
> > Tony
> Or it's just buffered? That was the problem the SqueakREPL students were having
> and why they switched to telnet: it's not (yet?) possible to set stdout and stdin
> to unbuffered, let alone 'raw' (as opposed to 'cooked').
> Best regards
The stdin for a Unix process will be blocking by default (a good choice for
processes that are expected to be chained in command pipelines, which is a
fundamental part of the Unix design). Squeak VMs inherit this behavior by
default, although more recent Cog/Spur VMs set the stdin to non-blocking mode
You can control this with:
<primitive: 'primitiveSQFileSetNonBlocking' module: 'UnixOSProcessPlugin'>
<primitive: 'primitiveSQFileSetBlocking' module: 'UnixOSProcessPlugin'>
Any Squeak VM will block on read from a blocking input stream. The two basic
strategies for dealing with this are 1) do the blocking read in a thread or
2) set non-blocking mode and use AIO notification to read the available input.
An example of setting non-blocking input from OSProcess/CommandShell is
the ExternalCommandShell REPL that sets nonblocking input in
For the stdin stream of the VM, either of these will set to non-blocking
if the VM has not allready done it for you at startup time:
OSProcess thisOSProcess stdIn setNonBlocking.
OSProcess accessor setNonBlocking: FileStream stdin fileID.
For perspective, the win32 overlapped files design is a thread based approach
(IIUC based on thinking from earlier DEC OSs with AST asynchronous traps handing
the low level IO processing). For a Squeak VM, the equivalent would be a blocking
input stream handled by a thread with asynchronous callbacks (see Eliot's
work with Aliens and FFI callbacks).
Unix applications are more likely to use AIO to accomplish similar things,
and the AIO based event notification in the Unix VMs is an example of this.
As far as I can tell, the two approaches are roughly equivalent, although
I suspect you could still get a good flame war going between VMS bigots
and Unix bigots if you were to raise the topic ;-)
If this subject has caused confusion for students, I would say that it's
a good thing :-) It is worth thinking about, especially as the world moves
to systems with more multiprocessing and concurrency issues.
More information about the Squeak-dev