Exceptions in attributes
Floris Bruynooghe
Currently psi uses structures with a status field for each value to,
e.g. pid_t pid; int pid_status;. You can then use PSI_STATUS_NI,
PSI_STATUS_OK, PSI_STATUS_NA and PSI_STATUS_PRIVS in the status field
to indicate the status of the field in the structure. When accessing
the attribute that uses this field we then get an exception if the
status is set to PRIVS, NA or NI. Essentially this means an attribute
of a class can either return the value or raise one of
AttrNotAvailableError, AttrInsufficientPrivsError and
AttrNotImplementedError.
This can be a bit limiting, I've run into a case where the kernel
returns an invalid zone id (solaris 10). So the current code can
either raise the appropriate exception at process creation time and
fail to create the Process object alltogether (which also results in
the ProcessTable failing) or set the status to PSI_STATUS_NA loosing
an awful lot of detail.
Instead I've been wondering if it would be worthwhile to change the
status field into two fields: one to store the exception type, or NULL
for PSI_STATUS_OK, and one to store the exception value. This way the
platform has more control over the exceptions and can rely more
detailed information specific to problems to exceptions. There are a
number of downsides however: (i) the structures grow rather a lot due
to the extra field. (ii) The platform code is now responsible for
creating the exception values which are python objects, while one of
the goals was to keep python as much out of platform code as possible
to avoid platform depended refcounting errors and the like.
The first issue can probably be solved by instead adding a linked list
of exception types and values to the structures. This way the status
field can refer to an index into the list and the space is not wasted
unless needed. At the price of some complexity however, there is now
the memory management of the linked list to think about.
The second issue can probably be solved by using a set number of
functions for creating the exception values. I'd think of the
equivalents of PyErr_Format() and PyErr_SetString() which should cover
most of the cases.
Thats what I could come up with however. Are there any other
solutions to this which I haven't thought off? I'm keen to hear your
opinions on this.
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org