#47: Tick Thread and better scheduling
-------------------------+--------------------------------------------------
Reporter: toots | Owner: toots
Type: Feature | Status: assigned
Priority: 5 | Milestone:
Component: Liquidsoap | Version: 0.3.4+svn
Resolution: | Keywords:
-------------------------+--------------------------------------------------
Changes (by toots):
* priority: 8 => 5
Old description:
> Liquidsoap consumes too much CPU on scheduling when empty or broken
> playlist is given.
>
> More generaly, we should have a scheduler that is capable of:
> * Scheduling new tasks immediatly
> * Go to sleep for some time if no task are to be executed for now
>
> This conditions are difficult to reach since the delay call cannot be
> canceled, so you can go to sleep but not wake up.
>
> My proposition is to add another "tick" thread that will perform regular
> actions based on a minimal delay.
> Then, using a global_sleep lock (as it is in place actually) in the
> scheduler, we'll be able to either wake it up every [delay] sec, or as
> soon as a task is scheduled.
>
> This tick system will also be very usefull for lastfm sumbission, later,
> and I suspect it may be of a great help for synchronisation
> debugging/managing..
>
> A proposed implementation is attached.
New description:
We should have a scheduler that is capable of:
* Scheduling new tasks immediatly
* Go to sleep for some time if no task are to be executed for now
This conditions are difficult to reach since the delay call cannot be
canceled, so you can go to sleep but not wake up.
My proposition is to add another "tick" thread that will perform regular
actions based on a minimal delay.
The idea is *not* to have yet another scheduling thread, but rather a kind
of internal clock that maybe used for simulating sleep and wake-up, or
trigger specific actions.
The actions that the thread will execute may not cost. Instead, you may
use it to submit a new task to the scheduler after some delay.
This tick system will be very usefull for lastfm sumbission, later, and I
suspect it may be of a great help for synchronisation debugging/managing..
A proposed implementation is attached.
--
Ticket URL: <http://savonet.rastageeks.org/ticket/47#comment:3>
Savonet <http://savonet.rastageeks.org/>
Let's program our stream !
