Hi,
I was looking over my old system.lib code thinking about how to improve the thread classes in there.
My old (read existing) Thread class operates something like this.
When the Thread class is constructed, only the properties are set up. No exec Task is created at this point.
Thread itself is inherited from Threadable, which in turn implements a pure interface called Runnable. Runnable defines as single method, namely run().
Thread is designed to take a different instance of Runnable and execute its run method. Hence it simply implements its own inherited run() method to call this other Runnable instance's implementation of run()
So you have two options to create some threaded code.
1) Derive Threadable directly and implement the run() method to do whatever you want your created thread to execute.
2) Implement Runnable for some class and feed it to the constructor of an instance of Thread.
To kick off your thread, you call start(), which is defined in Threadable and hence naturally passed on to Thread().
This creates a new amigados Process and ultimately gets it to execute the run method.
When the run method terminates, the thread cleans up and exists.
You can request (not force) the thread to stop by calling stop(). This sets a flag in the Thread implementation that any loops you implement in your run() method (or in code they call) is required to check periodically, using Thread::stopRequested()
The stop() method will not return until the process has ended. Calling stop will also interrupt any sleep state the thread is presently in (from calling Thread::sleep()), causing it to return a value signifying that the thread has been asked to quit.
The class destructor relies on this behaviour to ensure that everything is stopped and released before the destructor returns.
So, thats basically how it works so far. However, it has the implication that every successful call to Thread::start() actually creates a new Process.
What I am actually wondering is, how to improve it. Some ideas I have are
1) Have only the first call to start() create a new Process(). Rather than the thread exiting after the return from run() and subsequent cleanup, it would simply enter a wait state, all within a "while (!destructorInvoked) { }".
Subsequent calls to start() would then terminate this sleep state and this loop would repeat, re-invoking the run method.
In theory, it ought to be faster to (re)start threads after the first call to start() since you arent creating a new Process, simply reusing an existing one.
2) Add a list of ThreadStateObserver to the implementation. This would define a simple interface that has an notify() method. Whenever the Process is about to enter run(), has just exited from run(), is about to sleep, has thrown an exception that was caught by the system around the call to run() etc... the various observers could be notified. This would be a useful improvement on the current system.
This is to decouple the monitoring of threads from the threads themselves.
Any comments or ideas welcomed :-)
