Stefano Mazzocchi wrote:
> Thanks for the patch, but now I wonder: should we make this a more
> general component?
>
> I mean, sort of a 'heartbeat' thread in background does all sort of
> time-dependent things (cleaning up the cache, flush buffers, and so on)
>
> What do you people think?
I am working on that in Excalibur. This is the whole push for asynchronous
management I have been trying to sell everyone on. I already have some
Queues set up that are very efficient, the next part is writing the code
that manages the CommandQueue using a ThreadPool. The implementation will
allow for 3 types of "Commands" to be run:
1) Run now commands--add the callback to the queue and at the next oportunity
we execute the command (run only once).
2) Delayed run-once commands--add the callback to the queue and after a
specified period of time we execute it.
3) Repeated delayed commands--add the callback to the queue and after a
specified period of time we execute it. After that we place it back
in the queue with the new delay.
Commands in case 1 would be like asynchronous initialization code. It is
feasible to have a finite number of threads initializing all the components
asynchronously. This would speed the overall setup time for Cocoon. Some
Components are quick to set up, while others are more expensive.
Commands in case 2 would be for cache management, or automatically expiring
a resource after a certain period of time.
Commands in case 3 would be for routine maintenance of pools, etc.
This is also part of a generic Container implementation that I am creating
that takes advantage of all this power--and makes it easier to create
new Containers.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
