Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 24 Feb 2006 12:09:04 -0700

> recent exception discussion where
> some try to avoid copying 
> or even generating the error message,
> Bad: Sharing

My position is that references to internal storage of the exception object
should not be returned. The "const char * what()" interface is therefore
broken because, I might add, it uses evil sharing (note that returning a
reference to internal storage is a form of sharing). My proposal was to use
the "const char * what()" interface because it is a standard, but to return
only from it a linker allocated (forever lifespan) string.

Who is advocating not copying the error message? My position is that if the
dynamic part of the error message can be more compactly stored in the
initial exception payload as exception private data (not as a string) then
by all means do that. Later when they call "void context ( StringEditor & )"
the error string can be inflated into the StringEditor interfaced
destination storage. That just might be copying. Furthermore, my position is
that if we have to copy the error string into a rethrown exception then we
must copy it, but then it is best to store it using fixed sized
non-contiguous blocks so that we don't fragment memory. Again, all of that
just might be copying.

Finally, I don't think that anyone is advocating for not generating the
error message?

> with ideas to avoid copying arrays

I think maybe that this is a reference to the event queue design?

My position is that every single datum that is passed through the post event
interface is a unique copy, and not a reference to anything stored in the
database. The only question is whether this datum can be shared (reference
counted) when it is simultaneously placed in N event queues for N clients
that are subscribed.

The array in the subscription update has to be found in the data container
and copied to N pipes (one for each client that is subscribed). The question
is what agent will do this. There are really only two choices: It could be
the high priority record processing thread or the low priority server
thread. If it is the record processing thread then record processing load
will vary depending on N client loads. We try very hard to minimize this
impact today. One way to minimize that impact would be to reference count
data container interface references that reside in the event queues.
Reference counting is a very popular technique today (Java comes to mind).
So yes, the current design uses a form of sharing and sharing is generally
to be avoided, but this particular event queue design just might be a crux
situation that requires a carefully controlled form of it.

The alternative of course is to pump wire protocol directly into an event
queue based on fixed sized non-contiguous blocks. That is actually a
reasonably good approach (which I have considered), but the downside would
be that record processing would do almost all of the work and I am concerned
that I would be labeled the villain if we found out during final release
testing that record processing CPU consumption (note that this occurs in a
high priority thread) is heavily dependent on client loading. It is a very
important feature that we allow that what is needed out of the event
container may vary from client to client. Nevertheless, nothing is locked in
stone at this point and I should prototype this approach to see exactly what
the load increases might be.

Finally, I should add that if application specific, random sized, complex
data packages datum copies *are* placed on the event queue then the agent
that produces them can do the best job of doing the memory management for
them (they can use application specific free lists).

HTH

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System