On 1/4/01 12:04 PM, "Thomas Christen" <[EMAIL PROTECTED]> wrote:
> Obviously we are all thinking in the similar direction.
>
> My concept is to pack this functionality in a separate task with nested
> (parallel tasks). This would give the implementation full controll about
> (output-/log-handling - don't underestimate, shutdown - e.g. by the gui and
> max number of concurrent tasks).
>
> The join (and not - Wait until available ;-)) ) is done automaticaly inside
> the controlling task.
That approach has merit in scoping, however it complicates the internal
object model that is given to Tasks. If Tasks are layered like this, then
when modifying the object model there's an extra dimension to the way
changes can be made. It's more flexible, but harder to wrap your head
around.
I'd prefer to leave the internal object model in a very clear
target-task-data kind of structure.
Also, I'm not sure that explicit scoping of the thread's range of execution
is needed. I've done threading for years with executing a thread.start()
method and just knowing that a thread is running out there now and that I
could .join it, but otherwise it was on its way.
.duncan
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
