[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
File-length on pathnames
- To: Jon White <JLW@SU-AI.ARPA>
- Subject: File-length on pathnames
- From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
- Date: Tue, 19 Mar 1985 20:42:00 -0000
- Cc: common-lisp@SU-AI.ARPA, dzg@CMU-CS-SPICE.ARPA, Fahlman@CMU-CS-C.ARPA
- In-reply-to: Msg of 19 Mar 1985 04:14-EST from Jon White <JLW at SU-AI.ARPA>
The official party line is that Spice has no concept of a host.
In order to access a file on another machine, you embed that
filesystem into your filesystem. There is no reasonable way to talk
about access at the byte level or page level, since the only file I/O
primitives are reading and writing an entire file. This works fairly
well, since the file is only mapped when you read it, and the reading
not actually done until you touch the page. There is currently work
in progress to permit mapping of files and memory over the network.
When this capability exists, the problem will go away.
I find the restriction on FILE-LENGTH extremely silly. As near as
I can tell, the argument for requiring the restriction is the
- Some operating systems require an operation (which they may nor may
not call open, and is in any case not probably not identical in
semantics to the Common Lisp open) to be done before the length of
a file can be determined.
- This "operating system open" call may have some requirement for
exclusive access. If some other process has the file open, then
the call to FILE-LENGTH may wait or fail.
- It is somehow more intuitive to have OPEN wait or fail than to
have FILE-LENGTH wait or fail.
I think that if there is any implicit guarantee in the CLM
filesystem chapter that certain calls may not wait or fail whenever
they feel like it, then it is bogus. There is no way the CLM can hope
to describe the semantics of arbitrary filesystems, let alone the