Conor, Thank you for your competent feedback.
>I think we need to have a debate about whether nested tasks is a desirable >concept to implement. Whilst I can see how it might be desirable for your >approach to multithreading, it can open up a Pandora's box of complexity. I >don't think the debate last time was conclusive. > >Anyway, ignoring those concerns, let me give you some feedback on your >patch. Firstly, please update to the latest version from CVS before doing >your diff. I am not sure how you have done it but the patches you have >submitted would undo a whole stack of recent changes. Of course I would be glad to do this again. Only - if you first like to debate wether the concept is desirable or not (I would have no problem with a discussion about), I would rather save my time for more usefull work and probably do the work after - if still necessray. >OK. I still don't like the name :-). I would go for something like >TaskContainer. Not a bug deal No problem, I could change this. >You shouldn't be checking for non-exceptional cases in >the catch block, IMHO. Why not move this into the try block and handle it >there. Perhaps, a change in introspectionHelper would be needed to make that >work cleanly. In the end you are assuming that the cause of the build >exception is due to the inability to create a nested element, and that is >not a good thing. Well I completly agree. The reason was not to change too much of existing code and confuse too much people. Personaly I am rather a Person of doing it good and right and not only working. >It is an interesting question about who should be responsible for firing the >task started and task finished events. Should it be the task or the >container. I actually don't have a strong opinion either way. Handlers (Listeners) may depend on the correct order during task execution. Therefor I decided to pack it all together and make shure the order (lik a protocoll) is allways strict.
