Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 24 Nov 2014, 03:19
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Idea for a system timer API to replace polling in programs.
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 2 [24 Posts]   Goto page: Previous 1, 2
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2276

PostPosted: Thu 19 Dec 2013, 05:58    Post subject:  

"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.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5042
Location: Arizona, U.S.A.

PostPosted: Sat 21 Dec 2013, 00:30    Post subject:  

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.
.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2276

PostPosted: Sat 21 Dec 2013, 03:42    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4376

PostPosted: Sat 21 Dec 2013, 04:33    Post subject:  

amigo wrote:
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:
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

Quote:
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
Quote:
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)
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5042
Location: Arizona, U.S.A.

PostPosted: Sat 21 Dec 2013, 13:22    Post subject:  

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.
.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2276

PostPosted: Sat 21 Dec 2013, 13:43    Post subject:  

A program providing access to "its parts" is called IPC -which is what those little xml scripts (SOAP) you send to rox do. IPC is also what glues full desktop environments together -for gnome it's bonobo & Co. KDE has their own protocols also. dbus is the newest common IPC method -which is now used by nearly all DE's. Welcome to Dependency Hell!

Lately I've wondered if one could implement a light IPC using named pipes (fifos) which would be of any use...

I still tend to think that you have too wide a scope for your idea, though. I mean you have an idea which seems to require intervention on several levels. And, above all, cosmetic effects, etc., should be left to the end user. When you try to control every detail of the way an app looks, then you are bound to have headaches. I mean, even using a certain set of icons is not always a good -that's why we have themes so people can customize the final look for themselves.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5042
Location: Arizona, U.S.A.

PostPosted: Sat 21 Dec 2013, 14:46    Post subject:  

So many apps and services, so many protocols. It is quite the nightmare....

Using pipes for this is exactly the type of thing they do best, if they hold together.
You have my mind working on this train of thought...

The idea you refer to is the timer I presume. But it`s not cosmetic... WallPapers app.?
Realistically for time spans in the seconds, sleep is probably the best way.
And for times in the minutes+ cron would be the best method.


# Junction revisited ( Some things just won`t go away, huh.? ).
Need a wrapper app to catch all file system accesses from an app that it runs.
It would use a list of "path pairs" for substitution ( /etc=/path/etc:/usr/share=/path/usr/share ).
Run the Junction app with list argument, which then runs the main app argument.
.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4376

PostPosted: Sat 21 Dec 2013, 17:24    Post subject:  

gtkdialog would be one of the easiest programs to have non-polling event triggers
1) start an inotify watch on a directory where gtkdialog xml will go (actually glib has a wrapper that uses kqueue on bsd and something else on windows)
2) when a new gtkdialog xml file appears in said directory the watch will automatically trigger the xml to be parsed and run

The only reason I haven't patched gtkdialog for it is that I think its custom XML is a waste of development and the whole gtkdialog program should be reimplemented using gtkbuilder.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5042
Location: Arizona, U.S.A.

PostPosted: Sun 22 Dec 2013, 00:22    Post subject:  

I thought inotify only did file watches. You say it does dirs.? But only changes I take it.
My need is to catch accesses to given dirs within a shell instance.
So as in my Junction idea above, a "watch" is put on dirs for a child sub process.

GtkDialog needs scrapping, it`s nearly unusable. GtkServer may be a better choice.
Need a Gtk wrapper app that uses Visual Basic syntax to control the widgets.
I wrote a wrapper for GtkServer to do this, maybe I should drag it out and rework it.
Or perhaps if TinyC could be run in a shell wrapper it could do the same thing.


I`m thinking of apps that look for named pipes, then input and output info. and control.
But I think env. variables would be much more reliable than named pipes. Thoughts.?
.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 2 [24 Posts]   Goto page: Previous 1, 2
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0765s ][ Queries: 12 (0.0040s) ][ GZIP on ]