Re: What you get is what you want

Quartz wrote:
>>Maybe.  I think that there is many ways to arvertise the TM that a 
>>thread is blocked in an enqueue operation.
> 
> 
> But few or no other are safe and reusable.

By affirming that, do you mean that you have discovered all solutions? 
Humility is a vertu.


> safer: it is impossible to forget to unset the so said 'flag' upon return from the blocking action
> method call.

You don't understand me.  My proposal is that *only* the queue 
implementation (and maybe just a queue decorator) have a dependency to 
SandstormThread or SandstormThreadPool.  The EventHandlers don't need to 
  be aware of that.

> reusable: It avoids the dependency from the queue implementation (stage management layer) to the
> thread implementation (thread management layer).

What do you mean exactly by "stage management layer" and "thread 
management layer"?

 > [...]
> You certainly don't want the handlers to fool around with a thread flag

You are right, it's important that the EventHandler be independent of 
the internal mecanisms of Sandstorm.

> the stages and thread are not well isolated. 

I don't understand what you mean by "stages and threads isolation".

> I would add to that a very awfull lifecycle management.

Yes Sandstorm must shutdown and restart properly its stages.  I suppose 
that you use your "interruption handling" to achieve that?  A dedicated 
bus for "interruption" is a interesting idea.  Is there other utilities 
for "interruption handling" except shutdown and restart?

>>A more elaborate possibility could be to use the graph (with the help of 
>>StageGraph and StageEdge) of all stages to determine exactly where 
>>allocate and schedule our threads.  Contrary to other proposed 
>>solutions, this one is proactive instead of reactive.
> 
> 
> Computer system are always reactive. Think about it.
> This would 'simply' be a reaction to the stage graph.

My idea is to use the graph theory to modelise the system state.  We can 
adapt algorithms conceived for the Maxflow problem (see scientific 
literature) to our problem.  The goal is to have a more proactive 
behaviour of the system.

> The only way to be proactive is by prediting the requirements of a stage and provisionning it
> in advance with ressources. That means you read the future. If reading anything else, you are
> reacting to a consign (user input, config, etc...), a plan (config) or a feedback.

By proactive I mean "fast adaptability".

Jean


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click