Re: [User feedback request] Shepherd
 

Define "really efficient timer-based trigger mechanism". I use three ways of time-based triggering - alarmd, cron and asynchronous sleep(). The first one is good because AFAIK it can wake up the device even if it's turned off and uses almost no additional resources. Cron is, well, cron. Sleep() is far more precise and can be employed en masse if you can live with the resource penalty (we calculate when the event should occur and launch a thread that starts with sleep() at the beginning). If this does not answer you question, please elaborate :)

Re: [User feedback request] Shepherd
 

I would assume leveraging cron would be the most efficient (since I know nothing about alarmd), and I'm really just hoping to avoid a "sleep" based solution. I wouldn't want a bunch of threads spawned each just handling a single purpose event.

Most of the events I'm thinking about wouldn't need that kind of precision... it could be off by several minutes and it wouldn't matter to me.

Re: [User feedback request] Shepherd
 

Note that threads != processes. Threads are fairly cheap resource-wise (but not free). Of course if your plugin gets a separate process when it executes, but the sleep itself (when necessary) is not a big deal as it's inside the daemon process that is running anyway (also, even in those cases there is one extra thread per event -> we only schedule the next one).

Just a caveat, it's not just precision, but speed, too. If it's a sleeper thread, the 'payload' gets executed as quickly as possible (if it's native Qt code -> instantly). If we start from cron it always needs to load libs and startup and whatnot regardless of how complex the plugin is, and would feel a bit like trackerd ('what the hell is he doing with 100% cpu in the background again' syndrome). Don't forget - I'm scheduling, not polling !

Re: [User feedback request] Shepherd
 

I might be tempted to move over some of my own alarmd functionality to being an action of Shepherd so user's have more control over what happens.

I thought on Linux threads are just a special case of processes and the overhead is very similar? To me the issue would not be on resources but that the sleep() is meant for signaling and doing that in-process would be more efficient than over IPC.

Does anyone know about the level of precision or battery load required in using gobject's timeout_add or timeout_add_seconds? This would save from having to even spawn threads though it would require you to use a gobject main loop.

Re: [User feedback request] Shepherd
 

No, no, threads and processes are very different things. A thread is 'just' a separate thread of control in an application (all resources shared), while processes are completely isolated (shared memory notwithstanding). You can start literally thousands of threads in a second as nothing time/memory intensive 'needs to happen' as opposed to processes (which take up memory for their libs and data).

I have yet to do serious benchmarking, but during my experiments even the brute-force QThread::sleep() approach caused no noticeable battery load.

Re: [User feedback request] Shepherd
 

Below is my understanding, please correct if wrong:

The simplistic way to look at it is that threads and process are implemented on top of the same model. The main difference is whether a Copy-On-Write flag is set or not on the page tables.

I'd imagine if you just do a "fork"/"exec" then you end up losing all gains COW gains you. So I would guess the overhead is dependent purely on what you do with the process after the fork.

Re: [User feedback request] Shepherd
 

Yes, of course, I was talking about overhead from the aspect of this particular app (the DBUS and other notification mechanism voodoo-s bring a twist or two in the story). Performance-wise, since 2.6 kernels, the difference is not as prominent as previously, but still, AFAIK the penalty for creating a new process is larger than it is to create a new thread. Now, if one is to do an 'exec', it doesn't really matter if it's a process or thread, it's expensive either way :) The gain is in small, fast, native, reentrant modules that can be checked often without a serious penalty and are easy to communicate with (no process level IPC), and threads are actually very good for that.

Re: [User feedback request] Shepherd
 

I'm not saying that I know what is best... I just am glad to hear that performance considerations are being made from the start. It's a lot easier to think that way (and faster) than to go back and try to create performance at the end when people complain.

Kudos.

Re: [User feedback request] Shepherd
 

Hi all,
I have read the thread as it will be very handy to schedule the status of IM, for instance I'd like to set my Skype status to offline when I sleep and do not want to turn off my phone at nights (still need to receive cellular calls).
Any news if a test version of Shepherd is available ?
Cheers

Re: [User feedback request] Shepherd
 

We’re still all waiting for that mythical PR1.2 :(