Folks:
I've just updated CVS to an alpha quality version of the ACT (Asynchronous
Computation Task) module of Cygnal that I've been working on. It's not
ready for others to rely upon yet, but it is ready for examination and
review. It has in it a single-threaded scheduler that eliminates context
switch overhead generically for asynchronous and non-blocking I/O. The
other modules (IO, Net, HTTP) are in somewhat lesser stages of maturity,
but that means they're not done (rather than defect-laden).
I mention this because Rob and I have had some discussions about the
possibility of replacing libcurl in the client with this I/O system. If
curious, you may want to take a peek now.
Of rather more immediate interest generally is the system for white-box
testing I've implemented. I've implemented a version of aspect-oriented
programming using C++ templates. Now I do suppose this will be something
of a stress-test of template support, given that I found a compiler defect
in MSVC++8 while developing. (It's subtle; they were instantiating the
template at the wrong point.) And I won't claim at all that it's obvious
how to do this, or even (until you get the knack of it) to use them.
But they do allow a number of benefits. My original motivation for it was
to test the scheduler. I wanted my unit tests to be able to verify that a
certain order of execution was happening inside the scheduler. I've got a
number of these working now; they have been invaluable. More simply, but
still useful, I wanted to put an execution bound on the scheduler for
testing, to prevent a defective task from putting the scheduler in an
infinite loop during an automated test. I put an aspect point into the
main scheduler loop. The test aspect class implements such a bound; the
null aspect compiles into a no-op. See
cygnal/ACT/unit_tests/Test_Scheduler.cpp
for these how these tests are instantiated and used.
I should point out that I haven't felt the need for any logging code in the
scheduler. Where I've wanted to examine state I have put in an aspect
point (for the most part). When I do start doing logging (for the benefit
of the administrators), I plan on doing it with a logging aspect. From a
stylistic point of view, this technique eliminates the typical ifdef-nest
that logging and debugging code typically generate.
One of the advantages of this aspect idiom is that classes instantiated
with different aspects mangle up to different link-time names. This
eliminates many problems with version selection (i.e. with or without
debugging logs), as well as allow simultaneous versions to coexist
side-by-side.
Eric
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
