Gilbert wrote:
>At 11:01 AM 3/21/00 -0600, [EMAIL PROTECTED] wrote:
>>But wouldn't it be "nicer" if, instead of returning null, it returns an
>>error message describing what's wrong with the request, such as "out of
>>bounds memory allocation", or "XYZ has already allocated that resource",
>>and so on.
>
>For BCNI and Smart API, no exception should be thrown by a controller or
>factory. This has been a difficult architectural decision. In a multiple
>stage factory, null can be returned much faster than an exception.
Throwing
>an exception complicates every Smart API interface. It complicates
>interprocess communication.
Ok. How about if we return a "container" object, which is an instance of
what needs to be returned, but actually contains an error message?
So, we could have, say, a RAM controller which is actually an error
wrapper. If the user tried to access an area of memory in which they don't
have the security permissions, (say) a RamDeviceErrorController is
returned. Any access to it's methods would either throw an exception, or
do nothing, or print to a log file, or any other countless possibilities.
This way, the programmer still will not be able to access the requested
device, but errors can still be found.
Perhaps there's another way? If we re-do the URI structure, perhaps we
could do it in such a way that error messages can be stored internally:
public void example()
{
URI uri = "ram:device://localhost/iobus?start=0x220&end=0x22f";
RamDevice ram = (RamDevice) uri.getObject();
if (ram == null)
{
System.err.println("Got an error:" + uri.getErrorMessage()
);
return;
}
...
}
>>Also, how would one deallocate the resource? Would this need to be
>>specified in the finalize method of the resource's returned object? What
>>if the particular JVM that allocated this resource crashed, would the
>>resource then be unavailable to everyone, requiring a reboot? These
>>questions aren't just limited to your particular implementation; they are
>>serious things to consider for any system.
>
>After a resource has been "opened" by the URI-based subsystem, we need a
>corresponding way to "close" it. I expected that objects would implement a
>close() method. The close() method cannot fail. This would be consistent
>with work that has already been done on asynchronous I/O. (And a finalize
()
>method should invoke close().)
But, if the JVM crashes (say, a kernel function core dumps), then the
finalize() never gets called. That process which allocated the controller
is dead. The only way around this is to make the controller a system
shared object, which may not be that far off if the system shared resource
created the controller.
Perhaps this is for a larger scope. If a system shared object creates
another object, what memory space is that created object in? From what
I've gleaned from learning about JVM GCing, every shared object needs to
have all its created objects in the same memory space. But then, if the
controller creates objects specific for its current JVM process... What
kind of mess is this?
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
