User: Password:
|
|
Subscribe / Log in / New account

Are we really chasing the right issue?

Are we really chasing the right issue?

Posted Mar 3, 2012 2:05 UTC (Sat) by IkeTo (subscriber, #2122)
In reply to: Are we really chasing the right issue? by kevinm
Parent article: Short sleeps suffering from slack

Say I want to create a stop-watch application, the user specify a number of seconds to wait until an alert is shown, and meanwhile the stop watch will keep displaying the amount of time remaining, in seconds intervals. No user care if our display is updated 0.1 second too late, so the original sleep works perfectly. There is no need of "real-time scheduling class" requirement.

With the timer slack, all at a sudden users will see the timer being updated once fifteen seconds, and the final alert also late similarly. No user will miss such a "bug".

Now what option do I have?

1. I can ask the user to setuid root the program so that the program can use real-time scheduling, hoping that they have root privileges, and making every security sensitive user to raise their eyebrow.

2. I can ask the user to change the cgroup wide timer slack value, hoping that they have root privileges, and making the whole system wasting energy for all the time before the user/admin remember to reset the timer slack value, because they are now sleeping more than they do optimally.

3. I can stop sleeping at all, and instead use a busy loop with a very high nice level. Seems very drastic, waste a processor, waste power, make system load 1, but in a sense it is the best solution because it only affect the system for as long as the stop watch runs, and do not need root privileges.

How's that sound?


(Log in to post comments)

Are we really chasing the right issue?

Posted Mar 7, 2012 17:22 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

4. Write your program with a client/daemon architecture. The daemon can be activated as root by the system's daemon-managing services, then drop its privileges once it has given itself a real-time scheduling class. The client connects to the daemon via a socket, then sits in a blocking read() waiting for the once-a-second heartbeat packets from the daemon. If the daemon doesn't currently have any clients, it can just sit in a blocking accept() call until one shows up.

Admittedly this stops people on machines they don't administer from installing and using your application. However, if the user isn't trusted to have administrative access to the system, they probably shouldn't be self-installing applications that require policy violations to work as expected anyway.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds