Keep kernel running for execution of scheduled task

How can I keep a kernel running until all scheduled tasks have completed? For example upon running the following script bazinga.m:

RunScheduledTask[Print["Bazinga!"], {5, 10}]


with

$math -script bazinga.m  the kernel immediately exits and does not run the scheduled task at all. Setting $IgnoreEOF to True does not make a difference.

-
Can you clarify what you mean by "all scheduled tasks have completed"? Do you mean that all repetition of scheduled tasks have completed (and all tasks are set to have a finite number of repetitions---the default is infinite)? Or do you mean that if a given repetition of a scheduled task is being executed right now, the kernel shouldn't exit until the current repetition finishes? –  Szabolcs Jun 18 at 19:37
In example the kernel should quit after the scheduled task has been executed ten times. –  sakra Jun 18 at 19:40
this issue should be raised with wolfram support. At the very least the behavior should be documented. –  george2079 Jun 19 at 11:59
I have a ticket in with support for something that might be related: If you launch Mathematica 10 from Task Scheduler in Windows 7 x64 (with the "run whether user logged in or not" enabled), the front end launches in the background along with the two kernels, but one immediately dies. In v9 the front end and both kernels stay running, so if you pass a notebook as an argument in Windows Task Scheduler then in 9 it runs in 10 it doesn't. I'll report back when I hear back from support. –  DrBubbles Aug 6 at 18:44

I found a way to check for running scheduled tasks, but I am not sure, if the blocking behaviour of Pause is the best thing to do.

RunScheduledTask[Print["Bazinga!"], {5, 10}]
(* a lot of code *)
(* till the end of script *)


Output:

C:\Software\Dev>math -script test.m
"Wed 18 Jun 2014 21:14:15"
"Wed 18 Jun 2014 21:14:16"
"Wed 18 Jun 2014 21:14:17"
"Wed 18 Jun 2014 21:14:18"
"Wed 18 Jun 2014 21:14:19"
"Bazinga!"
...
"Bazinga!"
"Wed 18 Jun 2014 21:15:00"
"Wed 18 Jun 2014 21:15:01"
"Wed 18 Jun 2014 21:15:02"
"Wed 18 Jun 2014 21:15:03"
"Wed 18 Jun 2014 21:15:04"
"Bazinga!"
C:\Software\Dev>


Edit: Changed the index of "Running" boolean from -1 to 5. See the answer by Szabolcs.

Edit: Added the comments in the code sample to stress on the opportunity of doing stuff while the scheduler is running and now checking if ALL schedulers are done like is done in answer by Szabolcs.

-
nice workaround, but it seems to me if you need to do a While[..,Pause[]] to check for the tasks you may as well not use the scheduler and just execute the code in the loop.. –  george2079 Jun 19 at 12:05
I don't agree. You can do a lot of other stuff while the scheduler runs, can't you? And the while loop in the end of the script avoids it from quitting, when other things but the scheduler are done. –  Johu Jun 19 at 13:51
fair enough, i was thinking in terms of the example where the only thing in the script is the RunScheduledTask. The schedule task approach also likely has an advantage if you need precise timing. –  george2079 Jun 19 at 15:29

A better way to check if any scheduled tasks are active is

Or @@ ScheduledTaskActiveQ /@ ScheduledTasks[]


The reason why this is better is that it uses an API, thus it is more likely to be robust against future changes in the structure of ScheduledTaskObject. In the Raspberry Pi version current as of 2014-06-18, ScheduledTaskObject includes extra options at the end so [[-1]] won't work for checking if a task is active ([[5]] will though).

Warning: ScheduledTaskActiveQ[], called without arguments, will crash the kernel. ScheduledTaskActiveQ is a public System context symbol, but it does not seem to be documented.

-
Upvote for an API way. But I am not convinced, that undocumented function is more stable than fixing the index to 5. Also note, that ScheduledTaskActiveQ seems to be new in v9. –  Johu Jun 19 at 9:25
@Johu A System  context function is quite likely to stay stable long term, even if the documentation page happens to be missing. Also, if years from now it does break, and I'd need to look at it and fix it, it would be immediately obvious what ScheduledTaskActiveQ means while the meaning of [[5]] is a bit opaque without explanation. –  Szabolcs Jun 19 at 14:53