Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Why did I think of that?

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                                   

Process interrupt level based on mouse dynamics

  (+11)(+11)
(+11)
  [vote for,
against]

Processes running on your computer can 'interrupt' each other and, if your process has a higher priority than the one currently hogging processor time, it will be given some running time.

This idea is to base the interrupt priority of the UI process (which allows you to move windows, press buttons, etc.) on the dynamics of the mouse movement. So, if the user is, for example, watching a never-ending hourglass cursor on the screen and moving the mouse round and round in tiny circles whilst shouting "Wake up you bastard machine!" the UI will be given a high priority and the user will be permitted to press the 'Cancel' button.

I've seen a large number of computer users do this kind of rapid mouse movement in the expectation that the computer will react to it, so it seems sensible to make computers that will react to it.
hippo, Jun 06 2010

Event base programming http://en.wikipedia...t-based_programming
[goldbb, Jun 07 2010]

The type of asynchronous IO that I'm thinking of. http://en.wikipedia...tion_queues.2Fports
[goldbb, Jun 09 2010]

[link]






       I've seen people do that, too, but unless that is a different window system architecture from those I'm used to, pressing a button involves the application that owns that button. If that application is blocked waiting for something, no amount of prioritizing it will help.   

       I don't think this is a priority problem, but one having to do with the difficulty of implementing complicated operations in a way that lets them be interrupted, and with the difficulty of predicting whether seemingly innocuous steps - for example, looking up a domain name - will take a long time or not.
jutta, Jun 06 2010
  

       Hmm - you're right. It would be nice though if there was a way to get the behaviour the user expects: i.e. that moving the mouse frantically will cause the computer to pay attention and be more responsive.
hippo, Jun 06 2010
  

       <sarcasm> Because by default, we'd like to be ignored and sluggishly responded to? </sarcasm>   

       I don't know. Maybe in connection with power management. It could also emit the faint rumble of distant engines starting up. But mostly, this is an idea for a prettier magic wand.
jutta, Jun 06 2010
  

       [hippo]'s right. The psychology of the user is the given; any failure to accommodate it is a flaw, and no amount of "it's too difficult to implement, so you don't really want it" will change that. It's a bit more reasonable to say "It's a failure of the application programmer, not the OS," but I still feel the OS has failed if it doesn't handle badly written programs gracefully.   

       //without checking for cancel events//
How about: 1) all threads have a timeout interval 2) at its expiry, an ALRM signal (or something) is sent 3) threads that don't respond appropriately have their priority reduced, gradually, over time.
  

       4) Some threads, of course are supposed to run forever, but that would have to be specified explicitly. Even a programmer too lazy to write "abort gracefully on cancel" code might just specify a reasonable number for the timeout interval, when supplying arguments to create_thread() (or whatever), rather than just "infinity" every time.
mouseposture, Jun 06 2010
  

       [+] long standing bitch.
FlyingToaster, Jun 06 2010
  

       // [hippo]'s right. The psychology of the user is the given; any failure to accommodate it is a flaw, and no amount of "it's too difficult to implement, so you don't really want it" will change that.   

       I don't think anybody here argued that "it's too difficult to implement, so you don't really want it".
jutta, Jun 06 2010
  

       //I don't think anybody here argued that//
Neither do I. I associate you more with the position I described as being more reasonable than that one.
mouseposture, Jun 07 2010
  

       I think [mouseposture]'s point about the psychology of the user captures what I was trying to say. If the mental model the user has of the computer is one in which slamming the mouse down on the mousemat and then shaking it from side to side should elicit a response from the computer, then engineers should build computers which do respond to such input.
hippo, Jun 07 2010
  

       //long standing bitch//
We prefer to address her as "The Duchess of Cornwall".
(Whoops, there goes my knighthood)
coprocephalous, Jun 07 2010
  

       //then engineers should build computers which do respond to such input.// What happens when that part freezes up too?
xenzag, Jun 07 2010
  

       Then its time for the 3 lb. mallet, in order to strike any key properly.
RayfordSteele, Jun 07 2010
  

       One possible solution would be to replace *all* system calls which could potentially block with a nonblocking request-type system call; there would be one and only one type of blocking system call -- "wait for next completed event(s)."   

       The downside of doing this would be that, in practice, each regular (blocking) system call would need to be replaced by a (nonblocking) request call, followed by a dispatch loop (in which *at least* one "wait for event" call will be made), and thus more overhead.   

       Delays can still occur, though, if a program needs to do a lengthy calculation that doesn't involve any system calls... that program won't service mouse clicks, etc, until the calculation is done, or unless the author included an explicit "deal with events" call.
goldbb, Jun 07 2010
  

       when mice first became popular they were connected to the video card. Presumably a video card which had all the information on the windowing parameters could very easily toss an interrupt when a pertinent line was crossed(literally), which would mean that only relevant UI input gets to the CPU... which would mean people wouldn't need to buy the next gen processors for another year or so.
FlyingToaster, Jun 07 2010
  

       // so it seems sensible //   

       Yes, it does, but it's already too late ... the one that calls itself "Bill Gates" is already loose on your planet.   

       You're doomed.
8th of 7, Jun 09 2010
  

       bigsleep, you are correct, asynchronous is the term I wanted :) As for it being harder to code for, that would surely depend on what you were used to.
goldbb, Jun 09 2010
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle