[Openmcl-devel] buffering for socket streams
moore at bricoworks.com
Tue Nov 12 07:29:10 UTC 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/127.0.0.1), 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
> 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
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel