gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] ACT module; white box testing and aspect templates


From: Eric Hughes
Subject: [Gnash-dev] ACT module; white box testing and aspect templates
Date: Tue, 10 Jul 2007 08:41:56 -0600

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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]