Hello all: I too, use NO in real-time applications, and have a two commercial applications that utilize NO in data acquisition and servo control. I have also spent a fair amount of time implementing a version of the task handling as described by Wirth in his Tasks vs. Threads paper, and see this as a potentially viable path for those who need pre-emptive facilities, within a given class (tasks that have no context to preserve across many activations), using NO as the basis. This is very attractive, as NO is impressively powerful, but is compact enough that it can be understood and modified by one person. BB appears to follow this philosophy as well, and this is a major attraction. I agree with the comments of Dr. Sedlacek, in their entirety: NO and BB certainly have application to real-time projects. However, a serious consideration of which classes of real-time BB may be suited to is warranted. The impact of the GC on deterministic system behavior cannot be underestimated. I can understand the reasons as to why the current GC implementations are in use: when NO and BB are used as testbeds for the trial of concepts and approaches of compiler technology or other systems-level notions, a _functioning_ GC is sufficient. It is when we discuss hard real-time needs that the GC is found to be a significant issue. I personally can see great application for BB in hard real-time: I can easily envision applications in which one CPU is loaded very heavily handling multi-loop servo control and data acquisition. Another CPU would be free to offer additional services that are tightly time coordinated with the first, but that could not be accomodated as background tasks due to resource utilization. Now, there is an argument to made that faster CPUs come all of the time, and one might just wait to use a faster CPU (as the primary). The problem is, designers wish always to take advantage of this performance increase. Here, the problem is not neccessarily software largess in the commonly understood sense, but, compact software that requires increasing compute bandwidth. Another use for the multitasking (if not multiprocessing) is in applications in which a given task must be preemptable, and yet must preserve its state or context. Here, I am thinking of (a kind of) binary tree processing that is regularly, periodically interrupted (e.g., hard deadlines) so that I/O can be performed based on the tree processing result at that time, and where the state of the recursion must be preserved. This latter example is all but impossible to implement under NO, as far as I have been able to see, but could be easily done in BB. I have not studied the internals of BB to know what may be possible, but, I have considered the following with regard to NO, and its GC: 1. Remove automatic GC, and instead implement the calling of the GC under user control. This must be done with care, as some system elements require calling GC periodically to function properly. 2. Examine the core system for object usage, and redesign, where necessary and possible, using only statically allocated structures. Without the interface handling, the need for dynamic structures diminishes, and, in some embedded systems, the interface is dispensed with. This approach leaves the management of the GC totally at the user's descretion. 3. Remove GC and use Dispose (!) 4. Implement some type of incremental GC, that is bounded (e.g., deterministic) in its behavior. I have done 1, upon occasion. 4. appears to be the most desireable state of affairs, from my perspective. I would think that 4. would be a very interesting project, unfortunately, it is beyond my skill (I am trained in aerospace engineering, not computer science). An enterprising student may find this problem an attractive project, however(!). Thanks, Mike Michael McGaw, Ph.D. McGaw Technology, Inc.