Greetings,
I ported an Object Oriented infrastructure to work with the Linux
kernel about two years ago. For various reasons, that work was
dropped for a while. Now, upon picking it back up again, there
are some new features that were not present in the original port
that I need to support.
Among these is a simple exception support system. The core
of this system is based on the existence of a setjmp/longjmp
facility. In digging through the source code, I've found a
few, architechturally specific implementations of such a
facility, but no generalized, multi-platform support.
A FAQ I found seems to suggest this deliberate, and that such
support will not ever be added to Linux. Am I correct in
my understanding? If so, is an architechturally specific
implementation (such as was done for ppc) acceptable?
Thanks,
John S.
On Sun, 2003-02-09 at 22:10, John W. M. Stevens wrote:
> Among these is a simple exception support system. The core
> of this system is based on the existence of a setjmp/longjmp
> facility. In digging through the source code, I've found a
> few, architechturally specific implementations of such a
> facility, but no generalized, multi-platform support.
setjmp/longjmp are normally very hard to follow and maintain,
especially when the kernel has locks, sleeping rules and
multiple threads flying around.
You will see lots of code which does either
int foo_func()
{
alloc this
alloc that
_foo_func()
free this
free that
}
or has a single exit path and uses goto out type constructs
instead
> int foo_func()
> {
> alloc this
> alloc that
> _foo_func()
> free this
> free that
> }
Not that this matters any bit, but the proper order is of course
alloc this
alloc that
_foo_func()
free that
free this
even if only for aesthetical reasons :-)
(with locks, it does matter...)
Olaf
Olaf Titz wrote:
>
> Not that this matters any bit, but the proper order is of course
> alloc this
> alloc that
> _foo_func()
> free that
> free this
>
> even if only for aesthetical reasons :-)
>
> (with locks, it does matter...)
For locks it is only when you lock the order matters, not when
you unlock. For allocations there is of course the possibility
that the first allocation suceeds and the second fails, which
you must handle in some way.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
On Wed, Feb 12, 2003 at 11:55:32AM +0100, Kasper Dupont wrote:
> Olaf Titz wrote:
> >
> > Not that this matters any bit, but the proper order is of course
> > alloc this
> > alloc that
> > _foo_func()
> > free that
> > free this
> >
> > even if only for aesthetical reasons :-)
> >
> > (with locks, it does matter...)
>
> For locks it is only when you lock the order matters, not when
> you unlock. For allocations there is of course the possibility
> that the first allocation suceeds and the second fails, which
> you must handle in some way.
The usual way is with "pools".
Every resource allocated after a "mark" point gets dumped into
a separate pool, and then when processing returns to the mark
point, the pools are drained, one way or the other.
For locks, the pools are ordered, and you swim backwards through
the pool.
John S.