Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
I also don't think that this limited usefulness justifies the cost of running the service in every single Wine session. It should be started only when there are actually tasks to schedule.
The service also has a role of global xml task definitions storage, so that any client application could add or query task status, or check and change the task running state, and that's impossible to do without a service, similar to the functionality provided by services.exe.
Sharing global state doesn't imply a service, there are many other ways. That doesn't mean we can't have a service, but it doesn't justify having it run in every Wine session.
How the tasks I described already could be performed without a service?
There are plenty of ways to share global state, I'm sure you can think of a few yourself. Again, I'm not saying we can't have a service at all; but you need to find a way to not add extra cost to every single session for the sake of a few rare cases.
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand.