Premise: I have a calendar-like system that allows the creation/deletion of 'events' at a scheduled time in the future. The end goal is to perform an action (send message/reminder) prior to & at the start of the event. I've done a bit of searching & have narrowed down to what seems to be my two most viable choices
Unix Cron Jobs
Bree
I'm not quite sure which will best suit my end goal though, and additionally, it feels like there must be some additional established ways to do things like this that I just don't have proper knowledge of, or that I'm entirely skipping over.
My questions:
If, theoretically, the system were to be handling an arbitrarily large amount of 'events', all for arbitrary times in the future, which of these options is more practical system-resource-wise? Is my concern in this regard even valid?
Is there any foreseeable problem with filling up a crontab with a large volume of jobs - or, in bree's case, scheduling a large amount of jobs?
Is there a better idea I've just completely missed so far?
This mainly stems from bree's use of node 'worker threads'. I'm very unfamiliar with this concept
and concerned that since a 'worker thread' is spawned per every job, I could very quickly tie up all of my available threads and grind... something, to a halt. This, however, sounds somewhat silly & possibly wrong(possibly indicative of my complete lack of knowledge here), & thus, my question.
Thanks, Stark.
For a calendar-like system, it seems you could query your database to find all events occuring in the next hour, then create a setTimeout() for each one of those. Then, an hour later, do the same thing again. Then, upon any server restart, do the same thing again. You don't really need to worry about events that aren't imminent. They can just sit in the database until shortly before their time. You will just need an efficient way to query the database to find events that are imminent and user a timer for them.
WorkerThreads are fairly heavy weight items in nodejs as they create a whole separate heap and a whole new instance of a V8 interpreter. You would definitely not want a separate WorkerThread for each event.
I should add that timers in nodejs are very lightweight items and it is not problem to have lots of them. They are just stored in a sorted linked list and only the insertion of a new timer takes a little bit more time (to do an insertion sort as it is added to the list) as the list gets longer. There is no continuous run-time overhead because there are lots of timers. The event loop, then just checks the first item in the linked list to see if it's time yet for the next timer to fire. If so, it removes it from the head of the list and calls its callback. If not, it goes about the rest of the event loop work items and will check the first item in the list again the next through the event loop.
I'm using event structure and want to do some like Launchpad.
Numeric keyboard have for each number added a sound.
Problem is, that when I press number example one, the program is waiting when the music stop play and next I can press example number four.
Is it possible, to play sounds from 3 key's at the same time using event structure ?
I put the files online here and added screenshots below. Block diagram:
Front panel:
Working Solution
I think I got this working much more easily than I expected using the Play Sound File VI under the Graphics and Sound -> Sound -> Output palette. That link is the 2011 documentation (couldn't find a more recent link), but it does not look like it has changed. The working result is shown below, with two different events handled by the event structure:
Key Down? event:
Stop Button event:
You may be fine without using the Sound Output Clear VI to the right of the main event loop, but having it there won't hurt.
It turns out that the Play Sound File VI does not block, so you can play multiple overlapping sound files. If you run into blocking on your machine (one sound file plays, then the next, and so on), let me know because I have another solution that might work.
A word on events
An important thing to understand is that events are handled in a queue. When you press keys, those key presses go in order onto the event queue. Each time your event-handling loop executes, it takes the oldest event out of that queue and processes it. The event structure in LabVIEW will only handle one event per iteration of your event-handling loop. On the next iteration, if events are still in the queue that your structure is set up to process, it will take the next-oldest one for that iteration and repeat.
Now, lets say that you want to do some super complicated processing that takes 10 seconds every time you press a key, and you put that processing inside of your main event loop. Your key presses still go onto the event queue as fast as you press them, but LabVIEW has to wait the full 10 seconds before it can dequeue the next keypress and process it, so you end up with an application that seems to hang while it chugs through the queue much slower than you are adding items to the queue.
One way to get around this is to take that complicated processing and put it outside of the queue in another process. If you have the resources, you can actually call a separate instance of a processing sub-VI in its own thread for every one of those key presses. This allows the event handling loop to spawn processes as fast as you can press keys, and then your processes take whatever time they need to simultaneously (resources permitting) perform whatever actions you wanted.
Essentially that is what the Play Sound File VI is doing. It sees that you want to play a file and spawns a process to play that sound over the speakers, allowing the event-handling loop to continue immediately rather than waiting for the sound to finish playing. As you press more keys, more processes get spawn that kill themselves when they are finished. You can do this manually too, which is the other solution that I have for you if Play Sound File does not behave the same way for you as it did for me.
Update:
Thanks to #Engineero for pointing out that Play Sound File vi actually isn't blocking. The updated code shows how to play overlapping sounds. I'll leave it to the user to add the Stop Sound on Key Up code. No timeout is needed because nothing is taking place in the event structure.
Also, note that for me the Play Sound vi needed to be in a while loop to keep playing. Not sure why this is needed, but the NI examples sets it up this way (\examples\Graphics and Sound\Sound\Sound Player.vi).
Finally, you may crash the vi if your sound card gets overwhelmed as mentioned here. If that happens I would go with a better sound library to try and squeeze more performance out of your sound card.
Original:
First, I assume you a referring to this Launchpad?
I was able to press up to 4 keys at once will the following - the important thing is to set the event timeout to 1 ms. If you need more than that it will require a more sophisticated design.
I was no able to easily implement a sound because all the basic LabVIEW beeps are what's considered "blocking I/O" meaning if you call 2 Beeps simultaneously than Windows will play one after another not both at the same time. You will need to implement you instrument notes using non blocking I/O probably in a language other than LabVIEW such as this C++ library.
I'd like to write an extension that displays a desktop notification every day at a specified time. Having a quick look through the Chrome APIs, it seems like the only way to do this would be to:
create a background page for my extension,
use setInterval() with a sufficiently low resolution to not tax the CPU (even 5 min is fine),
when interval fires, check if the current time is after the desired time,
ensure that the user has not already been displayed the notification today.
(The details of the last step are irrelevant to my question, just put in to show I realize I need to prevent "flapping" of the notice).
This seems rather indirect and potentially expensive though; is there any way around this? Is the background page needed?
I suppose I could just call setTimeout() and only fire the event once (by calculating how long between now & desired time), then call it again after the notification is shown. For some reason that sounds more "brittle", though I'm not sure why...
I think you will want the background page to do this smoothly. You can't use a content script because you need to keep the "state"/timer.
So when background page first loads (browser start) you work out the current time and the offset to the next notification time and setInterval to that exact interval. That way you won't need to poll every five minutes and/or work out if you've shown the message. You simply show it at the exact time required. This has to be far more efficient, effective and cleaner than polling. At notification you just reset the interval again.
Some sample functions here:
setTimeout but for a given time
From reading the above post and from a quick search on the net it appears that you should have no problem calling setInterval for an interval such as once a day. Calvin suggests 25 days!
That is how I would approach it.
EDIT: Since posting one thing that has sprung to mind is what happens if a PC gets hibernated for n hours? I need to test this myself for a similar project so I will update once I've had a chance to test this out.
I know that flex does not support multi threading however, I would like to clear a doubt.
I have two events that call a same function. Suppose the two events occur at the same instant (or in quick succession) will the handler be called twice, one after the other or there is a chance that if the handler function is taking too much time to execute the same handler can start executing simultaneously.
Thnanks
The handler will be called twice, once with each event. The second call (and essentially, the entire app) will be blocked until the first call has returned.
Here's a nice overview of the event cycle--doesn't specifically address your question, but it's a nice broad picture.
And you can't go wrong with the elastic racetrack.
Yes it will always get called twice. Yes one of the two calls will complete before the other is started. Unless you are doing something like dispatching an event in the handler for another handler to work on, then it all goes out the window! Even then I believe the first call will complete, but the event it dispatched may get resolved before the second call happens, sometimes....sorta. ;)
YMMV
If you didn't know, using PixelBender, Flex can do multi-threading. Other than for graphics, you can make use of pixelbender to do mathematical functions quickly which you may find a use for :)
Can anyone give me a scenario where they think busy cursors are justified? I feel like they're always a bad idea from a user's perspective. Clarification: by busy cursors, I mean when the user can no longer interact with the application, they can only move their hourglass mouse pointer around and whistle a tune.
In summary, I think that the user should be blocked from doing stuff in your app only when the wait interval is very short (2 seconds or less) and the cognitive overhead of doing multi-threading is likely to result in a less stable app. For more detail, see below.
For an operation lasting less than 0.1 second, you don't usually need to go asynchronous or even show an hourglass.
For an operation lasting between 0.1 and 2 seconds, you usually don't need to go asynchronous. Just switch the cursor to the hourglass, then do the work inline. The visual cue is enough to keep the end-user happy.
If the end-user initiates an operation that is going to take just a couple of seconds, he's in a "focused" mode of thinking in which he's subconsciously waiting for the results of his action, and he hasn’t switched his conscious brain out of that particular focus. So blocking the UI - with a visual indicator that this has happened - is perfectly acceptable for such a short period of time.
For an operation lasting more than 2 seconds, you should usually go asynchronous. But even then, you should provide some sort of progress indicator. People find it difficult to concentrate in the absence of stimulation, and 2 seconds is long enough that the end-user is naturally going to move from conscious ‘focused’ activity to conscious ‘waiting’ activity.
The progress indicator gives them something to occupy them while they are in that waiting mode, and also gives the means of determining when they are going to switch back into their ‘focused’ context. The visual cues give the brain something around which to structure those context switches, without demanding too much conscious thought.
Where it gets messy is where you have an operation that usually completes in X time, but occasionally takes Y, where Y is much greater than X. This can happen for remote actions such as reaching across a network. That's when you might need a combination of the above actions. For example, consider displaying an egg-timer for the first 2 seconds and only then bringing in your progress indicator. This avoids wrenching the end-user from the 'focused' context directly to the 'waiting' context without an intermediate step.
It's not specifically the busy cursor that is important, but it IS important, absolutely, always to give feedback to the user that something is happening in response to their input. It is important to realize that without a busy cursor, progress bar, throbber, flashing button, swirling baton, dancing clown.. it doesn't matter ANYTHING- if you don't have it, and the computer just sits there doing nothing, the computer looks broken to the user.
immediate feedback for every user action is incredibly important.
I think you may well be right: in a decent asynchronous app, you never need to show a busy cursor. The user can always do something even if the big last operation is completing.
That said, sometimes Java apps like Netbeans or Eclipse, or even Visual Studio, hang with no busy cursor and no hope. But in that case, a busy cursor probably wouldn't help much either...but I think you're right: busy cursors are from a non-multithreading era for apps. In Flex apps, for instance, EVERYTHING is automatically event-driven callbacks, so setting a busy cursor would just be meaningless (though possible, of course).
You show a busy cursor when the user can not do anything until the operation is completed - including exiting the application.
I find it interesting that you don't see busy cursors in Web Browsers - perhaps that why people like them so much.
No, wait, I have a better answer. You show a busy cursor when the computer is thinking.
When one hits the Refresh button on a web browser, busy cursor must appear immediately to tell the user to let them know that a page is being loaded.
I think it was Don't Make Me Think that said that the tolerable loading time for human is zero second.
Google says:
Responsive
It's possible to write code that wins
every performance test in the world,
but that still sends users in a fiery
rage when they try to use it. These
are the applications that aren't
responsive enough — the ones that feel
sluggish, hang or freeze for
significant periods, or take too long
to process input.
There are two purposes for it:
Indicate for the user that something is happening.
Indicate for the user that nothing can't be done right now.
Busy cursor is better signal about the operation than nothing. For longer lasting operations something better should be used. For example browsers is still operational when a page is being retrieved and there is even a button to stop the operation. As the user interface is fully functional, there is no need to use busy cursor. However busy cursor can be used even in this kind of situations in the transition phases like when starting the operation or when stopping it.
I try to use them on any action that may take from 0.5 to 3 seconds, for longer actions I think progress indicators with enough information should be used.
I noticed with Fedora 8 at least that when an app sets the "busy" cursor, the "busy interactive" one is actually displayed. I guess this is because the system is still responsive to mouse input (like dragging the window etc.). As an aside, selecting the "busy interactive" cursor explicitly on linux is tricky:
http://www.pixelbeat.org/programming/x_cursors/
The only thing I believe the busy cursor does is it informs the user that ...
I'm not outright ignoring you, I'm just doing something else that may take awhile
While it is absolutely necessary to alert the user that your application is doing something, a busy cursor is only useful for the first few seconds of processing. For a delay of more than about 15-20 seconds, something else must be presented such as a progress bar, status message, message box, whatever. People assume your software has locked up after a minute or so and will try to terminate it. Sometimes, overall visual cues are just as important as a busy cursor.
For example, applications with tabs that do not respond with appropriate highlighting until the operation in the tab completes can be fixed up by updating the tab temporarily until all operations are complete. Sometimes, just a little optimization or refactoring will clean up horrible user interface responsiveness such as this.
I would use them only for quick completing things, like say under half a second. If anything takes longer than that then a progress dialog should popup, or a progress bar should appear in the status bar or somewhere else in the interface.
The user should always be able to cancel the action if it is taking too long to complete.
In response to the comment, the busy cursor would only be visible for the half second or so, as once the progress dialog is up it should change to being one of those "half busy" cursors, or just the normal arrow cursor.
You should avoid having a busy cursor up except in extreme circumstances, and if you think you need one, then think again and redesign.
For example, to indicate that you've clicked on a button, even though it's not done processing the event. If there were not some indication, the user might try to click the button again, causing all manner of badness.