Wakeup interface concerns (Was Re: changing the enum type)
david at fubar.dk
Mon Mar 2 08:35:06 PST 2009
(replying separately to this topic)
On Mon, 2009-03-02 at 16:10 +0000, Richard Hughes wrote:
> > (cf. the .Wakeup interface)
> What's wrong with it?
OK, so I'm looking at
(using a link to version 006 to preserve history for the archives)
This interface is not really well-designed. I tried to express that here
The main concern is that the presence of the signals leads you to
believe you can just connect to connect to the bus and then they get
delivered to you with some sane frequency.
Of course this won't work because then the daemon would have to wake up
all the time. Which coincidentally it used to do until I pointed that
There's also a (very slight) concern the data carried in the signals may
be privileged information; you may not be authorized to get this
information depending on how your system is set up.
So the signals need to go.
The other observation to make, once you realize that signals won't work,
is that having multiple different callers will cause measurement issues.
They literally step on each others toes with the way this work.
Another observation is that the wakeup interface is mostly just a power
user feature, it's really only something you need if you want a GUI-ish
powertop utility like you did in g-p-m.
So it's fine to only allow one caller.
So the proposal would be
o get rid of the signals
o make GetData() also return
- the data in the signals
- amount of msec since this was last read
in addition to the array of structs per process
o add methods to claim/release the wake up interface
- StartReadingData (OUT string cookie)
- StopReadingData (IN string cookie)
and only allow a single caller to do this. Remember to
watch for disconnects too.
and then users of this API would do
cookie = StartReadingData ();
while (<displaying dialog>)
stuff = GetData ();
<render stuff on screen>
sleep (<poll frequency>);
More information about the devkit-devel