Subject: Re: HSM implementation proposal
To: Henry W Miller <mill0440@gold.tc.umn.edu>
From: Jim Wise <jimw@numenor.turner.com>
List: tech-kern
Date: 12/08/1997 10:54:44
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, 6 Dec 1997, Henry W Miller wrote:
> Along with non-block reads there is anouther potentiol problem to
> consider: I was told when I first started using files that read(x) [ there
> is anotuehr parameter for a buffer, but I can't recall read schematics off
> the top of my head] would ALWAYS read x bytes, and return x. The only
> exception was when dealing with sockets. I wrote several programs, for
> class, that relied on this behavor. However an HSM file system may need
> to block read for a long time, thus if I try to read 1500 bytes, and only
> 500 are avaibal it would return 500 bytes. There may be programs out
> there that do not handle this situation. Word needs to get out that
> reling on this feature is about to break programs. (even if it is only
> student programs, I'd hope real world programmers don't do this, but now
> it is critical to not teach this bad habbit)
Read has _never_ been guaranteed to return exactly the requested number
of bytes -- if it were, what would happen if you requested more bytes
than remained in the file?
> I don't agree with wanting non-blocking, since it will probably be sued
> for polling, (though I agree there needs to be a way to ask for a file to
> be moved to local storage, and programs cannot block for that long)
> however the alternatives I see are requesting a read, and then a signal
> when the read is ready to complete, or a theading model that allows one
> thread to block while anotuer goes about working. I like the second one
> better, but both of them require major kernel modifications that I don't
> think we are ready for. If anyone can come up with an ellegant
> alternative to wasting cycles polling, that won't break existing programs
> please do.
There are several interfaces providing this already. See the man pages
for select() and poll(), and for the O_ASYNC and O_NONBLOCK options to
fcntl.
- --
Jim Wise
jim.wise@turner.com
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQEVAwUBNIwYShg+dMhCouwfAQFqFwf/R6memlvU9jcqpCBrB9R+1ddDAPgwbrsj
H1GBi5sqKoMGeXiltd5xX6gjD4KgP4AUFNcAJiWeesL2MdgflX3OOJqe/X3vNMrx
diLtZoS+u3im3fQukmAtKfgn0Uuzo76lIHYQmTUlPL/TmSEFuN7pVHJ1pdhuad68
9jr1xrab13wEBKyu49lhMh91n61K0FkPx/9ma0nO3JQ7QdKfQsCeOIhg7++iPwIR
lf2gAU63RzQCGt237bS1Oeil5bC1hcR8Vdb4k6EV/nUJfuHmWhTZdlsQcXM5tnY7
U6X3AwwXnn8hBJDnG4H42wL6DVwurTjmZDWkZzNToFOrfRjW+va4uQ==
=KR6f
-----END PGP SIGNATURE-----