skrenta@amix.commodore.com (Rich Skrenta) (06/14/91)
Two questions for fans of Amoeba or other capability-based systems.
Question #1:
An Amoeba server is only listening on a port if it is blocked in a
get_request(port, ...) call. Does this mean that if the server runs
out of threads executing get_requests that the service appears to vanish
to prospective clients? A client trying to locate the service port might
fail just because the service is busy. How is this dealt with in Amoeba?
client does:
do_operation(port, ...);
server does:
spawn_lightweight_threads(10);
for (;;) {
get_request(port, ...);
process_request();
put_reply(...);
}
If all 10 lightweight threads are tied up in process_request(), the server
won't be executing any get_requests on its port, and the client's do_operation
will fail.
Question #2:
The bullet file server returns a capability when you ask it to create a
file. The capability must be presented to perform operations on the file
such as read, write and delete.
capability = create_file(...);
Presumably you're supposed to add this capability to a directory or otherwise
responsibly manage it. But what if you "lose" it?
capability = 0;
The capability is not stored anywhere, but the bullet file server doesn't
know this. There is an unreferenced file on the file server with no
way to "garbage collect" it.
It seems that during the development of even a simple program there would
be potential to lose references to many files. Not even the programmer
whose errant program had created these files could reclaim them.
Is there a solution?
Rich
--
skrenta@amix.commodore.comgdtltr@brahms.udel.edu (gdtltr@limbo.org (The Befuddled One)) (06/16/91)
In article <2623@amix.commodore.com> skrenta@amix.commodore.com (Rich Skrenta) writes: =>Two questions for fans of Amoeba or other capability-based systems. => I am a fan, but I haven't actually had my hands on Amoeba, and it has been a few months since I have read the papers on it, so interpret my following remarks accordingly. =>Question #1: => =>An Amoeba server is only listening on a port if it is blocked in a =>get_request(port, ...) call. Does this mean that if the server runs =>out of threads executing get_requests that the service appears to vanish =>to prospective clients? A client trying to locate the service port might =>fail just because the service is busy. How is this dealt with in Amoeba? => => client does: => do_operation(port, ...); => => server does: => spawn_lightweight_threads(10); => for (;;) { => get_request(port, ...); => process_request(); => put_reply(...); => } => =>If all 10 lightweight threads are tied up in process_request(), the server =>won't be executing any get_requests on its port, and the client's do_operation =>will fail. => => I believe that the Amoeba kernel keeps a cache of ports that have been recently "get_request"ed. If an incoming request matches an entry in the cache but not an a waiting get_request, it is held in limbo for a certain amount of time. A get_request in that time will handle (one of) the waiting request(s). Otherwise, the request is discarded. =>Question #2: => =>The bullet file server returns a capability when you ask it to create a =>file. The capability must be presented to perform operations on the file =>such as read, write and delete. => => capability = create_file(...); => =>Presumably you're supposed to add this capability to a directory or otherwise =>responsibly manage it. But what if you "lose" it? => => capability = 0; => =>The capability is not stored anywhere, but the bullet file server doesn't =>know this. There is an unreferenced file on the file server with no =>way to "garbage collect" it. => =>It seems that during the development of even a simple program there would =>be potential to lose references to many files. Not even the programmer =>whose errant program had created these files could reclaim them. =>Is there a solution? => I believe that the BFS periodically consults the directory server and packs all the referenced files to the far ends of the disk. In this process, all files not referenced in the directory server are overwritten/freed. Ok, time for everyone to tell me how wrong I am. :-) =>Rich =>-- =>skrenta@amix.commodore.com Gary Duzan Time Lord Third Regeneration -- gdtltr@brahms.udel.edu _o_ ---------------------- _o_ [|o o|] To be is to be networked. [|o o|] |_o_| Disclaimer: I have no idea what I am talking about. |_o_|
ast@cs.vu.nl (Andy Tanenbaum) (06/18/91)
In article <2623@amix.commodore.com@ skrenta@amix.commodore.com (Rich Skrenta) writes:
@Two questions for fans of Amoeba or other capability-based systems.
@
@Question #1:
@
@An Amoeba server is only listening on a port if it is blocked in a
@get_request(port, ...) call. Does this mean that if the server runs
@out of threads executing get_requests that the service appears to vanish
@to prospective clients?
If all the threads stay busy until the client times out, yes. In Amoeba
6.0 this property will go away, and the machine will remember ports even
when no threads are listening. This will be achieved by a new system call
that announces ports to the kernel (set_port_list).
@Question #2:
@
@The bullet file server returns a capability when you ask it to create a
@file. The capability must be presented to perform operations on the file
@such as read, write and delete.
@
@ capability = create_file(...);
@
@Presumably you're supposed to add this capability to a directory or otherwise
@responsibly manage it. But what if you "lose" it?
It will eventually be garbage collected. Normally you access the servers
through standard library routines that take care of registering capabilities
in directories for you, so they don't get lost. If you make the low-level
calls directly, then you have to be careful not to lose them.
Andy Tanenbaum (ast@cs.vu.nl)
P.S. Please excuse use of @ for >. Necessary to trick stupid program intocondict@danton.osf.fr (Michael Condict) (06/18/91)
In article <2623@amix.commodore.com>, skrenta@amix.commodore.com (Rich Skrenta) writes: > Question #1: > > An Amoeba server is only listening on a port if it is blocked in a > get_request(port, ...) call. Does this mean that if the server runs > out of threads executing get_requests that the service appears to vanish > to prospective clients? A client trying to locate the service port might > fail just because the service is busy. How is this dealt with in Amoeba? > The server is expected to always have at least one thread blocked in a get_request. Even if it doesn't, the client won't fail until and unless timeout occurs in its transaction before any of the threads of the server get back to the top of the loop and take another request. The client can set any desired timeout in each transaction. The difficult part is deciding on a reasonable timeout. When I worked on Amoeba, we were coming to the conclusion that 1 to 2 seconds is adequate for any well-designed server on a local area network. Note that this timeout affects only the wait for a server to take a request. It does not specify how long the server is allowed to take to carry out the request. Thus a server can always avoid client timeout by using the standard technique of invoking a new server thread whenever all server threads are busy. The hairy issue is "service" timeout. Currently, Amoeba does not allow the user to limit the amount of time the server is given to carry out a request. Once a malicious server takes your request, you are blocked until it decides to let you proceed. I argued that Amoeba can never be a robust, secure system until service timeout is implemented, but I don't know if they have it yet. > Question #2: > > The bullet file server returns a capability when you ask it to create a > file. . . . > Presumably you're supposed to add this capability to a directory or otherwise > responsibly manage it. But what if you "lose" it? > . . . > The capability is not stored anywhere, but the bullet file server doesn't > know this. There is an unreferenced file on the file server with no > way to "garbage collect" it. > This one is easy, really. It is required that any object you want to remain around permanently be "touched" periodically, meaning the STD_TOUCH operation must be performed upon it, to indicate interest in the object. If you enter the capability in the directory graph, this will happen automatically, because the object manager that does garbage collection first traverses the directory graph, touching everything it sees. If you don't enter it into a directory that is reachable from the "super" root directory, you are responsible for periodically executing something that will touch it. Otherwise it will be destroyed by the object manager within 24 hours or so (this is adjustable). Michael Condict European Research Inst. Open Software Foundation Grenoble, France
wolfe@orion.sybase.com (Dave Wolfe) (06/19/91)
In article <2623@amix.commodore.com> skrenta@amix.commodore.com (Rich Skrenta) writes: >Two questions for fans of Amoeba or other capability-based systems. >Question #2: >The bullet file server returns a capability when you ask it to create a >file. The capability must be presented to perform operations on the file >such as read, write and delete. > >Presumably you're supposed to add this capability to a directory or otherwise >responsibly manage it. But what if you "lose" it? > >The capability is not stored anywhere, but the bullet file server doesn't >know this. There is an unreferenced file on the file server with no >way to "garbage collect" it. Why do you say there is no way to garbage collect it? We had a similar problem at BiiN with our file system (also capability based). We called these files "unnamed files" and actually considered them a feature (temp files). What we did was inform the file server every time the active representation (in core) of a file object was being garbage collected. The file server decided whether the file was unnamed or not. If it was unnamed the disk space was deallocated. I don't know what Amoeba does, but I will bet it is similar. -DaveW >Rich >-- >skrenta@amix.commodore.com
wolfe@orion.sybase.com (Dave Wolfe) (06/20/91)
In article <2623@amix.commodore.com@ skrenta@amix.commodore.com (Rich Skrenta) writes: >@Question #2: >@ >@The bullet file server returns a capability when you ask it to create a >@file. >@Presumably you're supposed to add this capability to a directory or otherwise >@responsibly manage it. But what if you "lose" it? In article <10238@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >It will eventually be garbage collected. Normally you access the servers >through standard library routines that take care of registering capabilities >in directories for you, so they don't get lost. If you make the low-level >calls directly, then you have to be careful not to lose them. Still doesn't answer the question of "what if you lose them?" Isn't there also a possible window between the time the file/object is created and the time a directory entry is made? Seems like you have a storage leak problem in the event of a failure. -DaveW