Idea for a system timer API to replace polling in programs.

[sunburnt]

# Code discussion: amigo commented on how bad polling is, I know this all too well. Cron?

I`m thinking system timers ( .5, 1, 2 , 5, etc...) that each run app lists that are "env" variables.
This way there`s only one timer running for each time interval. Not one running in each app.

# An API utility would be needed to add, modify, and delete apps in the env variables.
.

[Flash]

How does Puppy know when a keyboard key is pressed? Surely polling would be too slow. Keyboards have an internal controller chip, but how does it tell the computer that a key was pressed? Is there an interrupt dedicated to the keyboard?

[sunburnt]

Hi Flash; Apparently the keyboard is polled at maybe 200 to 1000 times a second.
This seems way too fast, human beings are no way near that fast.
And kinda disappointing also, you`d think better use would be made of hardware interrupts.

[Flash]

Nobody can type that fast, for sure. Probably the reason the keyboard is polled so often has to do with latency or delay. When you hit a key, you expect the response on the screen to be instantaneous. A millisecond is the same as instantaneous to our limited brains.

Is the polling done by the computer's motherboard or by the keyboard's built-in controller?

[Moose On The Loose]

Hi Flash; Apparently the keyboard is polled at maybe 200 to 1000 times a second.
This seems way too fast, human beings are no way near that fast.
And kinda disappointing also, you`d think better use would be made of hardware interrupts.

IIRC:
IRQ-1 was used in early PCs before the USB keyboard came on the scene.
When IRQ-1 happened, the BIOS did some stuff and then some Rube Goldberg things happened letting the code check a circular buffer for keys.

There was a bizarre bit of code on early laptops that each time you pressed a key restarted a down counter that timed how long until the thing went into power saving mode.

[sunburnt]

Ahhh yes... The haphazard evolution of the PC. How sad that there was no real planning.

The keybd. offers output to the PC`s port, the O.S. ( Linux ) decides when to look at it.

[Flash]

The reason I brought up the keyboard at all is that how it works might have some application to this particular topic. The OS must respond with very little delay when a keyboard key is pressed, and it must not miss any keystrokes. How do it do it?

[sunburnt]

I`m not sure, but I`d think the keybd. has a fifo buffer to hold the key strokes.
When the O.S. gets around to looking at the buffer, it empties it all.

[amigo]

Right you are -there's a buffer. As for the Interrupts, they can follow very quickly -the kernel is always ready for an interrupt and they can happen, potentially, many thousands of times per second.

cron is the answer -except that the bottom time-limit is 1 minute. Of course, there are other methods too. If the desired action involves kernel 'events', then a udev rule can be used to trigger an action only when the event occurs. Most of the time when a polling-loop has been considered as the answer, it is because the underlying idea has not been properly sorted.

Exactly what are you trying to do?

[greengeek]

I guess both the keyboard and mouse would have to have a pretty high priority as far as the OS 'looking' at their output - although, having said that, I do find there are plenty of times where flash objects running / loading in my browser seem to prevent the OS from looking at either mouse or keyboard at all...

[technosaurus]

are you looking to come up with something that handles hibernation and suspend well?
If so, your huckleberry is /sys/class/rtc/rtc0/wakealarm or possibly
/sys/devices/virtual/misc/rtc/power/wakeup
(you can use the date command to write the wakeup time to it as shown here)
and you can use init facilities to run stuff on thaw/resume

As for events here is some applicable example code:
http://www.xmailserver.org/eventfd-bench.c
http://www.xmailserver.org/timerfd-test.c
http://www.xmailserver.org/signafd-test.c
more here:http://kernelnewbies.org/Linux_2_6_22#h ... 16912acec2

[sunburnt]

Hi guys; The spark here was my Separate Desktop Wallpapers app using polling.
I also have my usb-auto app that auto mounts / unmount usb devices that`s polled.

I`d mentioned before about having a set of system timers instead of using "sleep 1".

I did not know that cron only had a resolution of 1 minute. So it`s no help here.

Out of curiosity... amigo; You`re saying the keybd. is hardware interrupted.? Mouse too.?

# My suggestion of an API system timer:
Using "sleep" is asynchronous, so accurate to the second timing isn`t needed here.
I was thinking "sleep 0.1" and have a counter to provide the other time intervals.
However, this may be more cpu intensive than just having multiple sleeps running.
As I said the timer events would look at env variables for lists of apps to run.
env variables: $SLEEP01, $SLEEP02, $SLEEP05, $SLEEP1, etc...
So writing apps as daemons ( like my Wallpapers app.) with a sleep-loop isn`t needed.
The app is called and it does whatever the daemon usually did during each timed loop.

# Calling the apps is a sys. load, so 1 second and under may not be a good idea.
If the app runs with a polled loop, then there`s no sys. load of firing up another shell.

# Wacha think guys.? Is this just another dumb idea, or does it have merit.?
.

[technosaurus]

Take a look in may simple icon tray code. It uses a gtk wrapper around inotify to handle file events without polling (my earlier code used inotify directly, but I wanted portability to windows). The most recent version also handles the desktop background. It is really simple to update any image, for bg, just cat the new image over the default.
you could do something like this:

Code: Select all

sdesk -b /usr/share/backgrounds/default.jpg &
while :; do
for x in $HOME/backgrounds/*;do
sleep 30
cat $x >/usr/share/backgrounds/default.jpg
done
done

The trayicons and tooltips work the same way.

[amigo]

udev is a great way to handle auto-mounting of USB devices. The kernel event triggers udev into action and you can create udev rules to call an external program for each event.

I see no point at all in having a loop which does something for desktop backgrounds. These should simply be set and then forgotten until the next time you want to change. BTW, controlling the background (root window) image is the rightful domain of the Window Manager. Some of them allow for using different images for each virtual desktop -some of them do not. rox and some other desktop-related programs impinge on this control. In your case, both JWM and rox are trying to control it, while you are trying to impose your own will... If you want to control it, then you need to disable both jwm and rox from doing so.

[jamesbond]

udev is a great way to handle auto-mounting of USB devices. The kernel event triggers udev into action and you can create udev rules to call an external program for each event.

+1

[amigo]

"You`re saying the keybd. is hardware interrupted.? Mouse too.?" All hardware is provided with an IRQ -an Interrupt Request number. The kernel is constantly checking the IRQ's to see if any hardware needs attention. The fact that playing video slows down mouse sometimes shows how the kernels' task-scheduler is working. The scheduler prioritizes interrupts according to one of several methods.

You can switch the scheduler type on-the-fly -but only within the confines of which schedulers were enabled at kernel compile time. You can also set the timer frequency. Different settings of the two (timer 'ticks' and scheduler type) work best for different systems -according to the type of load, etc. So no interrupts are processed until the kernel thinks it is time to do so. Another kernel option which comes into play is the pre-emptable settings.

A real-time kernel is patched/configured to modify the way the standard kernel deals with interrupts and pre-emption. I'm not suggesting that a real-time kernel would be better or should be used. real-time support is mostly useful for mission-critical processes which must run in real-time -although rt kernels are helpful for high-performance audio to avoid skips in the output.

[sunburnt]

Lots of subjects broached here. I`d like to address them one by one.
I`m always ready to learn "How Things Work" ( My favorite book as a kid ).

amigo; Since you brought it up, what about web video and the Flash player / codec.
Most players have video progress and a cached progress too.
So if the video is cached ahead, why does it freeze when the connection`s interrupted.?
This to me seems to be the crappy Flash player / codec, if it`s cached it should continue.
In fact if the whole video were cached then you could rip it ( something they don`t want ).

It kinda looks like a scam by the internet providers to sell you a faster connection.
A slow connection should have no problem at all with a good amount of the video cached.

# And... Can Bash use udev.? An example of trapping a desktop switching event.?
In fact, if apps were written with hooks like this, then they`d provide their own events.


SFR and NathanF gave me xml code ( yuck ) to set Rox`s background.
This works well, except Rox insists on deleting it`s xml background line if it`s a bad /path/file.
Same sort of xml crap I ran into working with Xfce when it`d delete it`s own files.

technosaurus; Your example looks like sdesk is the controller.
1) Why cat the file instead of just copying it.? ( I`m sure there`s a reason...).
2) How does catting the file cause sdesk to refresh the desktop.? Rox must be "prompted".

For Saintless`s Wheezy project he`s using idesk, it`s similar to sdesk I presume.?
Note: I still don`t see how an applet inserts itself into the various trays.

# All too often a daemon is a polled time-loop, my wallpapers and usbauto apps in point.
Both of these are specific events that should be easily trappable for any language.
.

[amigo]

Switching desktops is never gonna cause a kernel event. The kernel can only respond to hardware events. When something happens it notifies udev, udev looks through its rules and if one matches the event, then it does whatever the rule says to do.

For things like mounting removable disks when attached, udev can easily handle them -but the mount code shouldn't be directly run by udev. Rather, udev should notify an external program to do it. This is because udev runs during boot-up, before any desktop is present. Hence, it could not run some desktop notification. Instead, it should run some script which detects whether there is a desktop at all and if so, which one to notify/open-filer, etc.

Even though an audio/video is completely cached before hand, it can still be interrupted by other events -there are many other things going on while it is being played which deserve at least a chance to be processed -like moving the mouse, etc. Or perhaps the MS system should be used, where, you move the mouse and a small window pops up which says: You have moved the mouse. Windows will now reboot to update the system so your mouse-move can be recognized... He He...

The xml code for use with rox is not bad. At least the directuives are very short -not like trying to read even a small gtkdialog program. Sure, I hate xml -to read it esepcially. But for IPC with rox it is fine and allows lots of little tricks.

catting instead of copying preserves file attributes which could be changed by using cp.

If you want to 'trap' a desktop event, then you need for the WM to do that. I know you don't like that answer, but there are plenty of good reasons that tasks are divied up between lots of levels and programs. If it were not so, the trapping a desktop event would require that the Xserver handle those events. Heck, why not throw the Xserver right into the kernel, along with the shell and all the programs -and have a huge monolithic blob like MS???

The idesk that I knew of was simply a utility for creating 'desktop' icons with an action associated with them. It does provide a universal way of having icons, but each WM/filer combination must be provided the means of working with them. For example, instead of having an icon directly open a dir with rox-filer, instead it should detect which filer is being used and open the dir with that.

[technosaurus]

For example, instead of having an icon directly open a dir with rox-filer, instead it should detect which filer is being used and open the dir with that.

Rox basically just reimplemented xdg-open ... puppys wrapper for it is:

Code: Select all

case "$1" in 
        '')exit;;
        *://*) exec rox -U "$1";;
        *@*.*) exec rox -U "mailto:${1}";;
        *) exec rox "$1";;
esac

... I think it would be wise to split that out of rox btw and use standard xdg utils

1) Why cat the file instead of just copying it.? ( I`m sure there`s a reason...).
2) How does catting the file cause sdesk to refresh the desktop.? Rox must be "prompted".

1. some cp implementations rm then mv which breaks the inotify watch and would complicate the code
2. rox does not take advantage of inotify

Note: I still don`t see how an applet inserts itself into the various trays.

WM_HINTs ... look in the source for gtkstatusicon or eggtray or jwm (WM hints do all kind of stuff with title, borders, size, stack, ... well technically they do nothing except "hint" to the wm how they want to be treated if the wm has the ability)

[sunburnt]

Extremely concise answers guy. I thank you for your expertise.

Being as apps ( in this case JWM, Rox, IceWM, etc.) don`t issue event reports, polling is "it".
Nearly all apps that I attempt to deal with provide no access to "their parts". Even GtkDialog.

Time for more reading. Google, Google, Google.
.