Notices

Originally Posted by attila77

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

Originally Posted by twoboxen

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.

Originally Posted by attila77

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

Originally Posted by attila77

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).

Originally Posted by epage

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.

Originally Posted by attila77

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)..

Originally Posted by epage

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.