mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] pclsr


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] pclsr
Date: Wed, 22 Jun 2011 19:34:32 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1

   Date: Wed, 22 Jun 2011 11:53:33 -0700
   From: Matt Birkholz <address@hidden>

   If Unix's non-PCLSRing(?) operations are losing, why load them up with
   all of the state of an encrypted channel?  Your problem may be the
   same problem that caused GIO to avoid FUSE and go asynchronous.

For what it's worth, I wasn't using fuse -- I was using puffs,
NetBSD's analogue of fuse, which does work asynchronously.  I worked
around this instance of the problem by fixing psshfs (the puffs
analogue of fuse's sshfs) to cache attributes that it is about to send
off to the server.  It already cached attributes that it just read
from the server, but that did no good in the case Scheme choked on.

                                                                    Using
   GnomeVFS directly keeps all that channel state on the near side of the
   kernel.

I don't want to get Gnome involved on any of my systems...

   I had to do a violence to generic-i/o performance, I'm afraid.

We need to do violence to the port system to get any performance out
of it.  Binary ports should be buffered by default, so that READ-OCTET
can be open-coded, with unbuffered ports as a special case of buffered
ports, and character I/O should be layered on top of that.  Right now
everything is optimized for the character I/O case at the expense of
the binary I/O case.

You're right that we'll need to use buffers outside the heap to talk
with, e.g., aio, or any other asynchronous I/O system provided by the
operating system.  That will be necessary only for the buffers of
ports that do I/O with the outside world, of course, not ports
internal to Scheme.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]