[Openmcl-devel] buffering for socket streams

Timothy Moore moore at bricoworks.com
Mon Nov 11 23:29:10 PST 2002

Thanks for the information.  What effect does :interactive have on 

I don't blame any gross inefficiency in the streams code, or indeed any 
performance problem in openmcl itself.  I do suspect it's something 
like you suggest: waiting too long for I/O to complete.  I'm just doing 
a very unscientific comparison between CLX/CMUCL on a 1Ghz x86 Linux 
laptop and CLX/openmcl on a 700 Mhz iBook; the openmcl combo has 
visible pauses as each character is rendered on the screen.  Granted we 
shouldn't be writing one character at a time through X, but in the 
CMUCL case we seem to be able to get away with it.

On Monday, November 11, 2002, at 10:21  PM, Gary Byers wrote:

> Is the client talking to the server via the loopback interface
> (localhost/, or via a regular IP address ?  (In either
> case, I wonder if there's any way to sniff local traffic.)
Yes.  I would like to get Unix domain sockets working too.

> I've been meaning to ask John Wiseman where to find his CLX port
> for .. oh, however many months it's been since he announced it.
> Maybe I should try to find it and see what ktrace/sniffing/poking
> around and guessing reveal.
There are some notes in the McCLIM sources on getting and building CLX  
for openmcl.  I think we have all the relevent patch files in the 
sources too.
> If I had to guess, I'd say that we're "waiting too long for I/O
> to complete" rather than "not buffering enough and therefore making
> too many I/O calls", but a guess based on some packet/system call
> traces would be a more informed guess ...
Is there any way to tune that waiting?  Or is long wait the result of a 
context switch?


Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list