h a l f b a k e r yA dish best served not.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
- DotNet has application domains. Communication
between each one requires serialisation and
deserialisation.
- If interdomain objects were stored in a seperate memory
space, shared by all appdomains, such
serialisation/deserialisation wouldn't occur.
- Objects would need to be "owned" by a
domain though,
to prevent errors.
- A simple example of this is of information flowing from a
network interface (in AppDomain A), through to a process
(in AppDomain B), another process (in AppDomain B), then
back again to the network inferface, through the other
domains.
- The simple example can be implemented by asking for a
large amount of unmanaged memory. The memory is
treated as an infinate circular address space. When data
is allocated it is taken from the end, when data is
deallocated, the space is marked as dead, and when a
consecutive set of dead space is straight after the start, it
is reclaimed, by moving the definition of start. So
AppDomain A, would create an array of received bytes, it
would pass the reference to AppDomain B, which after
processing would pass the reference to AppDomain C.
Eliminating, serialisation/deserialisaion between. The
memory access would need to be syncronised for thread
safety. Each appdomain would only need to deserialise.
- A more complicated version is to create the
SharedObject class which every inter-appdomain data
class needs to inherit. The unmanaged memory wrapper
would need to implement a GC similar to .NETs. On
construction the SharedObject class would obtain a
memory handle, the SharedObject. All primatives would
need to be reimplemented as SharedString, SharedInt
etc.. The outcome would be that, no deserialisation will
need to occur between appdomains either.
- Of course running out of memory in the first chunk of
allocated memory would require more being allocated,
then joined together to form a single logical block.
- I'm sure there's much more that would need to be done
but...
- This would be heaps easier if the CLR was simply coded
to support AppDomain SharedMemory.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I thought of a way to implement this, and a slight
change which makes it better. |
|
| |
Mono is an open source CLR. You could create a
branch which implements Portable memory space,
for use between AppDomains. |
|
| |
Because you're not copying the object, it's
possible to have object handles in both
AppDomains, but the object should only be
allowed to be accessed by one at a time. |
|
| |
The changes would require adding an extra bit to
each object, which indicates if it's a shared
object. The object would also need a field to
store which appdomain has control. |
|
| |
The programmer would need to make sure that
references are nulled in a AppDomain relinquishing
control. The JIT could enforce that this happens,
either doing for the programmer, issuing warnings
that the programmer forgot, or even throwing an
exception. References on the stack which are
blocked to to a Syncronous call to another
AppDomain would not need to be nulled. |
|
| |
Other challenges. The shared object's class must
be consistent between AppDomains. |
|
| |
Application of AppDomain shared memory. Any
pipeline oriented application. Such as application
servers, which use AppDomains to isolate and
protect from erroneous code. |
|
| |
Performance of AppDomains (as well as complexity
of using them), hinders widespread use and
reaping the benefits from having more reliable
applications. |
|
| |
Perhaps this is the wrong way to go about it?
Maybe we need another layer of container - an
ExceptionDomain? It all runs in one AppDomain,
has the same single security context, but you can
have different isolated areas, where memory,
thread and stack errors can be isolated. |
|
| |