Re: JDK-8146527: Absolute Scheduling/Request for Comments

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling/Request for Comments

David Holmes-6
I suggest you start a discussion on [hidden email] if you expect to see certain behavior here. What you will get will depend on how the OS API's behave - and whether the JVM suspends or continues to run as a background app. As already noted the Windows API does not work as described. I don't know how iOS or Android behave here.

There is a big difference between trying to define a "one size fits all" API, versus defining a common programming model. The programming model for mobile apps is very different to regular server based applications. As I said the way a mobile app has to handle backgrounding and sudden termination is more akin to the old applet lifecycle: init, start, stop, destroy - where you could loop from stop back to start indefinitely as you navigated away from then back to the page hosting the applet. The need to handle this was an explicit part of the applet programming model, and is also an explicit part of the native programming model for mobile apps.

David

> -----Original Message-----
> From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of Markus KARG
> Sent: Sunday, January 10, 2016 6:06 PM
> To: [hidden email]; 'concurrency-interest' <concurrency-
> [hidden email]>
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> As a contributor to JavaFX I need to chime in here. Actually JavaFX *does*
> provide a one-size-fits-all API independent of underlying platform (desktop,
> browser or mobile). Oracle's recent commitment to port Java SE to mobile
> platforms supports this. So maybe the core team should accept that the
> paradigm what Java SE covers shifted slightly here? As soon as Java SE will be
> available on Android (and prototypes exist already), Java SE programmers will
> expect the schedulers to work "correctly" in hibernated environments.
>
> -----Original Message-----
> From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of David Holmes
> Sent: Sonntag, 10. Januar 2016 05:34
> To: 'concurrency-interest'
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> Continuous convergence? How you write mobile apps is completely different
> to how you write regular applications. One programming does not fit all - by a
> long stretch.
>
> Mobile app programming has more in common with old Applet programming
> than anything else in SE Java.
>
> David
>
> > -----Original Message-----
> > From: [hidden email] [mailto:concurrency-
> > [hidden email]] On Behalf Of Carsten Schipke
> > Sent: Sunday, January 10, 2016 1:36 PM
> > To: [hidden email]
> > Cc: concurrency-interest <[hidden email]>
> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> >
> > Considering the continuous convergence of all platforms nowadays, that
> > should not be a ?mobile programming model?.. Portability was once a
> major
> > feature of Java. The JVM & Java have some technical debt to pay to make
> > that true again for current times/platforms/technologies.
> >
> >
> > > On Jan 10, 2016, at 11:07, David Holmes <[hidden email]>
> > wrote:
> > >
> > > Yes for mobile this is part of the programming model and it needs to be a
> > primary consideration. Hence the various event hooks to allow for this.
> > >
> > > David
> > >
> > > From: [hidden email]
> [mailto:concurrency-
> > [hidden email]] On Behalf Of Joe Bowbeer
> > > Sent: Sunday, January 10, 2016 8:58 AM
> > > To: David Holmes <[hidden email]>
> > > Cc: concurrency-interest <[hidden email]>
> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> > >
> > > On mobile platforms, such as Android (or J2ME), suspension is
> > commonplace, and even force-termination for resource reclamation or
> > battery preservation is common.
> > >
> > > For both these reasons, app developers need to deal with these
> > eventualities explicitly, saving and restoring persistent state, and cannot
> rely
> > only on a scheduled executor service.
> > >
> > > On Sat, Jan 9, 2016 at 2:07 PM, David Holmes
> <[hidden email]>
> > wrote:
> > >> It is "by design" in the sense that:
> > >>
> > >> a) nothing in the Java platform APIs, or the VM implementation, were
> > designed to work across machine suspension
> > >> b) the underlying Window's API's do not behave in the way that is being
> > described.
> > >>
> > >> David
> > >>
> > >> > -----Original Message-----
> > >> > From: [hidden email]
> > [mailto:concurrency-
> > >> > [hidden email]] On Behalf Of Markus KARG
> > >> > Sent: Sunday, January 10, 2016 3:51 AM
> > >> > To: 'Nathan & Ila Reynolds' <[hidden email]>; 'Carsten Schipke'
> > >> > <[hidden email]>
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Nathan,
> > >> >
> > >> > thanks for your comments.
> > >> >
> > >> > Please note that the actual behaviour deviates from your expectation
> > on
> > >> > varying with the OS type and version. For example, the one-time-
> trigger
> > >> > "schedule(delay)" variant of JDK 8u66 on Win 8.1 (64 Bit) does *not*
> fire
> > the
> > >> > event "very soon after the delay" in some cases; in fact, it adds the
> > complete
> > >> > duration of the hibernation to relative-ms. Hence, when you call
> > >> > "schedule(1min)", hibernate for 30s, wakeup the PC, then the event
> > actually
> > >> > fires 90s after you invoked that command! In fact, that behaviour is
> *by
> > >> > design* as I learned (according to Oracle's David Holmes), and it is the
> > reason
> > >> > for filing this RFC.
> > >> >
> > >> > -Markus
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Nathan & Ila Reynolds [mailto:[hidden email]]
> > >> > Sent: Samstag, 9. Januar 2016 18:19
> > >> > To: 'Markus KARG'; 'Carsten Schipke'
> > >> > Cc: [hidden email]
> > >> > Subject: RE: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Also, Windows fires an event to all applications when the system
> > resumes
> > >> > after hibernation.  You could use that event instead of polling.
> > >> >
> > >> > ScheduledExecutorService provides schedule(),
> scheduleAtFixedRate()
> > and
> > >> > scheduleWithFixedDelay().  I expect schedule() to run the command
> at
> > or
> > >> > very soon after the delay or as soon as the machine resumes if the
> delay
> > has
> > >> > elapsed.  I expect scheduleAtFixedRate() to run the command N times
> > >> > rapidly if hibernation lasted N periods.  I expect
> > scheduleWithFixedDelay() to
> > >> > run the command one time at or very soon after the delay or as soon
> as
> > the
> > >> > machine resumes.  In this regard, the programmer has control
> whether
> > they
> > >> > need N times or 1 time after hibernation.  I only use
> > scheduleAtFixedRate() if
> > >> > I have something staying in sync with the passage of time.  I use
> > >> > scheduleWithFixedDelay() in all other cases because if the command
> > takes a
> > >> > long time, I don't need it to run right away.
> > >> >
> > >> >
> >
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledE
> > >> > xecutorService.html
> > >> >
> > >> > -Nathan
> > >> >
> > >> > -----Original Message-----
> > >> > From: [hidden email]
> > [mailto:concurrency-
> > >> > [hidden email]] On Behalf Of Markus KARG
> > >> > Sent: Saturday, January 09, 2016 6:58 AM
> > >> > To: 'Carsten Schipke' <[hidden email]>
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Carsten,
> > >> >
> > >> > the Windows API provides several different methods for timing. Some
> > of
> > >> > them are definitively able to fire at a particular point in time,
> > independent of
> > >> > any hibernation.
> > >> >
> > >> > In case a different OS won't have such a factility, there is a simple
> > fallback:
> > >> > Triggering events more often, checking the actual time (in pure Java),
> so
> > we
> > >> > find out whether to wait further, or whether the event is to be fired.
> > This,
> > >> > BTW, is the workaround applied by pure Java solutions currently,
> hence
> > what
> > >> > I'd like to get rid off by this feature request. :-)
> > >> >
> > >> > -Markus
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carsten Schipke [mailto:[hidden email]]
> > >> > Sent: Samstag, 9. Januar 2016 14:09
> > >> > To: Markus KARG
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > sure, as I mentioned, I have never really had that requirement, it just
> > >> > sounded to me like many programmers could have many slightly
> > different
> > >> > requirements on such an API. I also don?t know what the Windows
> API
> > >> > offers in those regards / how its solved there, but if there is such a
> > widely
> > >> > accepted solution, then it surely would make sense as you say.
> > >> >
> > >> >
> > >> > > On Jan 9, 2016, at 21:04, Markus KARG <[hidden email]>
> > wrote:
> > >> > >
> > >> > > I think it should be up to the programmer (e. g. by passing a flag or
> > using
> > >> > different methods) whether he wants 10 events after missing those
> > while
> > >> > hibernation, or whether he wants the events to be collapsed into one
> > single
> > >> > event alternatively. BTW, I never said that the API must support an
> > absolute
> > >> > variant of repeated event schedulung. You could also simply provide
> an
> > >> > absolute variant of the "fire ONCE" method, and the mail application
> has
> > to
> > >> > reschedule inside of the event handler.
> > >> > >
> > >> > > Hooks are out of scope for my proposal, as they solve a different
> > problem
> > >> > and are working on a deeper level (the scheduler API could certainly
> > make
> > >> > use of such hooks). In case the Windows API for example would be
> able
> > to
> > >> > solve the problem for us (it is, BTW), why shouldn't we provide a Java
> > API
> > >> > wrapping that (without running into any rattail, as we simply offload)?
> > >> > >
> > >> > > -Markus
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Carsten Schipke [mailto:[hidden email]]
> > >> > > Sent: Samstag, 9. Januar 2016 11:02
> > >> > > To: Markus KARG
> > >> > > Cc: [hidden email]
> > >> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute
> Scheduling
> > /
> > >> > Request for Comments
> > >> > >
> > >> > > ?...or it will fire instantly after the end of hibernation ?? considering
> > your
> > >> > example of hourly/periodically checking mails, that would mean that
> the
> > >> > program checks your mailbox 10 times at once after 10h hibernation.
> > >> > > So the API would also need to know whether unfired events should
> > queue
> > >> > up over time. Sounds like a rattail pulling endlessly use cases &
> > requirements
> > >> > behind it.
> > >> > >
> > >> > > I for one never thought about using the JVM to schedule things that
> > live
> > >> > through hibernation or similar (not knowing the original intention of
> the
> > API).
> > >> > But I have also never built daemon-like desktop/client
> > applications/services.
> > >> > >
> > >> > > I guess in case of JVM, one could argue that specifications only apply
> > at
> > >> > runtime, and hibernation is interrupting that. Maybe it would be
> better
> > to
> > >> > provide hooks e.g. in the Runtime class to allow callbacks on pre-
> /post-
> > >> > hibernation, standby, signals etc. Then one could de/attach events
> > >> > accordingly.
> > >> > >
> > >> > >
> > >> > >> On Jan 9, 2016, at 17:28, Markus KARG <[hidden email]>
> > >> > wrote:
> > >> > >>
> > >> > >> The following requests comments on a Feature Proposal for
> > Absolute
> > >> > Scheduling.
> > >> > >>
> > >> > >> OpenJDK ticket JDK-8146527
> > (https://bugs.openjdk.java.net/browse/JDK-
> > >> > 8146527) describes the following case:
> > >> > >>
> > >> > >> * ScheduledExecutorService.schedule() is invoked to schedule
> firing
> > of an
> > >> > event "in one minute".
> > >> > >> * The laptop lid gets closed instantly after that, so hibernation will
> > occur,
> > >> > hence the JVM will suspend.
> > >> > >> * After thirty seconds of hibernation, the laptop lid gets openen, so
> > >> > hibernation will cancel and the JVM resumes.
> > >> > >> * Despite the expected result (one minute after start of program
> the
> > >> > event does occur), the event actually is delayed by the length of the
> > >> > hibernation phase, and happens 90 seconds after the program was
> > started.
> > >> > In the expectation of the end user, the event fired 30 seconds "too
> > late"!
> > >> > >>
> > >> > >> This is annoying to users and rather unexpected and astonishing for
> > >> > programmers literally following the words of the JavaDocs. Clearly the
> > >> > provided deadline is a relative value in the physical sense ("one
> minute
> > from
> > >> > now, independent of what 'now' is currently like"), but certainly what
> > the
> > >> > user actually expects it to work like is an absolute value in the physical
> > sense
> > >> > ("one minute from now, where 'now' is the current point on the time
> > axis of
> > >> > the Universe, hence unaffected by hibernation). Whether or not the
> > laptop
> > >> > was closed temporarily in the meantime plays no role to the
> expectation
> > of
> > >> > neither the end user nor the application provider.
> > >> > >>
> > >> > >> Unfortunately there is no other API that allows the application
> > vendor to
> > >> > define that the deadline it meant to be unaffected of hibernation.
> > Clearly
> > >> > this is a drawback to the Java platform, as many applications need such
> a
> > >> > behaviour (like "check my mails once per hour" - if you open your
> laptop
> > lid
> > >> > ONLY for a few minutes to see whether meanwhile new emails
> arrived
> > or not
> > >> > [like, BTW, some laptops are able to perform these days, even with
> the
> > lid
> > >> > closed, thanks to a BIOS timer] you won't receive any new emails ever
> > as
> > >> > "JVM" time progresses only be few minutes per day then).
> > >> > >>
> > >> > >> A solution could be the addition of a special variant of
> > >> > ScheduledExecutorService.schedule(absoluteInstant) which is
> > unaffected of
> > >> > any hibernation, and will fire either exactly at the absoluteInstant (in
> > case the
> > >> > laptop is not hibernating _currently_), or it will fire instantly after the
> > end of
> > >> > hibernation, in case the laptop was hibernating at absoluteInstant.
> > >> > >>
> > >> > >> There are two possible ways to reach this: Either there is an OS-
> > specific
> > >> > API that alrady provides exactly that behaviour, or the JVM needs to
> be
> > >> > informed every 'x' fractions of "discontinuous jvm time" to find out
> how
> > >> > much "continuous real world time" has advanced and whether a
> > scheduled
> > >> > event was missed meanwhile (which is the workaround such
> > applications
> > >> > have to perform on their own currently to workaround the problem).
> > The
> > >> > first is problematic due to changes in the implementations of the APIs
> > (e. g.
> > >> > Windows changed some APIs from "continuous time" to using
> > >> > "discontinuous time"), the second is complex in finding the optimal
> > value of
> > >> > 'x' (too low means high power consumption, too high means firing too
> > late
> > >> > after the deadline).
> > >> > >>
> > >> > >> Side note: To be unambiguous, the new deadline should possibly
> be
> > >> > typed as java.time.Instant, as that could never be misunderstood as
> > >> > "discontinous jvm time" inherently.
> > >> > >>
> > >> > >> What is your opinion on that?
> > >> > >>
> > >> > >> -Markus
> > >> > >> _______________________________________________
> > >> > >> Concurrency-interest mailing list
> > >> > >> [hidden email]
> > >> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Concurrency-interest mailing list
> > >> > [hidden email]
> > >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Concurrency-interest mailing list
> > >> > [hidden email]
> > >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >>
> > >>
> > >> _______________________________________________
> > >> Concurrency-interest mailing list
> > >> [hidden email]
> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > [hidden email]
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling/Request for Comments

Joe Bowbeer
A possible intermediate solution to consider is more support for pause-able executor services.

I've written several of these over the years for different situations and different platforms, but I think a common API is possible. Generally, on pause I want to be able to pause execution of queued tasks and do something with tasks that are already running (let them run? each task can pause itself?), Then, on resume I want to adjust the scheduled execution times of queued tasks before resuming execution. I want to be able to perform the rescheduling programmatically rather than automatically, though some reasonable default behavior might be possible.

Would support for pause/resume help in this hibernate use case described?

On Sun, Jan 10, 2016 at 2:54 PM, David Holmes <[hidden email]> wrote:
I suggest you start a discussion on [hidden email] if you expect to see certain behavior here. What you will get will depend on how the OS API's behave - and whether the JVM suspends or continues to run as a background app. As already noted the Windows API does not work as described. I don't know how iOS or Android behave here.

There is a big difference between trying to define a "one size fits all" API, versus defining a common programming model. The programming model for mobile apps is very different to regular server based applications. As I said the way a mobile app has to handle backgrounding and sudden termination is more akin to the old applet lifecycle: init, start, stop, destroy - where you could loop from stop back to start indefinitely as you navigated away from then back to the page hosting the applet. The need to handle this was an explicit part of the applet programming model, and is also an explicit part of the native programming model for mobile apps.

David

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of Markus KARG
> Sent: Sunday, January 10, 2016 6:06 PM
> To: [hidden email]; 'concurrency-interest' <concurrency-
> [hidden email]>
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> As a contributor to JavaFX I need to chime in here. Actually JavaFX *does*
> provide a one-size-fits-all API independent of underlying platform (desktop,
> browser or mobile). Oracle's recent commitment to port Java SE to mobile
> platforms supports this. So maybe the core team should accept that the
> paradigm what Java SE covers shifted slightly here? As soon as Java SE will be
> available on Android (and prototypes exist already), Java SE programmers will
> expect the schedulers to work "correctly" in hibernated environments.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of David Holmes
> Sent: Sonntag, 10. Januar 2016 05:34
> To: 'concurrency-interest'
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> Continuous convergence? How you write mobile apps is completely different
> to how you write regular applications. One programming does not fit all - by a
> long stretch.
>
> Mobile app programming has more in common with old Applet programming
> than anything else in SE Java.
>
> David
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]
> > [hidden email]] On Behalf Of Carsten Schipke
> > Sent: Sunday, January 10, 2016 1:36 PM
> > To: [hidden email]
> > Cc: concurrency-interest <[hidden email]>
> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> >
> > Considering the continuous convergence of all platforms nowadays, that
> > should not be a ?mobile programming model?.. Portability was once a
> major
> > feature of Java. The JVM & Java have some technical debt to pay to make
> > that true again for current times/platforms/technologies.
> >
> >
> > > On Jan 10, 2016, at 11:07, David Holmes <[hidden email]>
> > wrote:
> > >
> > > Yes for mobile this is part of the programming model and it needs to be a
> > primary consideration. Hence the various event hooks to allow for this.
> > >
> > > David
> > >
> > > From: [hidden email]
> [mailto:[hidden email]
> > [hidden email]] On Behalf Of Joe Bowbeer
> > > Sent: Sunday, January 10, 2016 8:58 AM
> > > To: David Holmes <[hidden email]>
> > > Cc: concurrency-interest <[hidden email]>
> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> > >
> > > On mobile platforms, such as Android (or J2ME), suspension is
> > commonplace, and even force-termination for resource reclamation or
> > battery preservation is common.
> > >
> > > For both these reasons, app developers need to deal with these
> > eventualities explicitly, saving and restoring persistent state, and cannot
> rely
> > only on a scheduled executor service.
> > >
> > > On Sat, Jan 9, 2016 at 2:07 PM, David Holmes
> <[hidden email]>
> > wrote:
> > >> It is "by design" in the sense that:
> > >>
> > >> a) nothing in the Java platform APIs, or the VM implementation, were
> > designed to work across machine suspension
> > >> b) the underlying Window's API's do not behave in the way that is being
> > described.
> > >>
> > >> David
> > >>
> > >> > -----Original Message-----
> > >> > From: [hidden email]
> > [mailto:[hidden email]
> > >> > [hidden email]] On Behalf Of Markus KARG
> > >> > Sent: Sunday, January 10, 2016 3:51 AM
> > >> > To: 'Nathan & Ila Reynolds' <[hidden email]>; 'Carsten Schipke'
> > >> > <[hidden email]>
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Nathan,
> > >> >
> > >> > thanks for your comments.
> > >> >
> > >> > Please note that the actual behaviour deviates from your expectation
> > on
> > >> > varying with the OS type and version. For example, the one-time-
> trigger
> > >> > "schedule(delay)" variant of JDK 8u66 on Win 8.1 (64 Bit) does *not*
> fire
> > the
> > >> > event "very soon after the delay" in some cases; in fact, it adds the
> > complete
> > >> > duration of the hibernation to relative-ms. Hence, when you call
> > >> > "schedule(1min)", hibernate for 30s, wakeup the PC, then the event
> > actually
> > >> > fires 90s after you invoked that command! In fact, that behaviour is
> *by
> > >> > design* as I learned (according to Oracle's David Holmes), and it is the
> > reason
> > >> > for filing this RFC.
> > >> >
> > >> > -Markus
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Nathan & Ila Reynolds [mailto:[hidden email]]
> > >> > Sent: Samstag, 9. Januar 2016 18:19
> > >> > To: 'Markus KARG'; 'Carsten Schipke'
> > >> > Cc: [hidden email]
> > >> > Subject: RE: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Also, Windows fires an event to all applications when the system
> > resumes
> > >> > after hibernation.  You could use that event instead of polling.
> > >> >
> > >> > ScheduledExecutorService provides schedule(),
> scheduleAtFixedRate()
> > and
> > >> > scheduleWithFixedDelay().  I expect schedule() to run the command
> at
> > or
> > >> > very soon after the delay or as soon as the machine resumes if the
> delay
> > has
> > >> > elapsed.  I expect scheduleAtFixedRate() to run the command N times
> > >> > rapidly if hibernation lasted N periods.  I expect
> > scheduleWithFixedDelay() to
> > >> > run the command one time at or very soon after the delay or as soon
> as
> > the
> > >> > machine resumes.  In this regard, the programmer has control
> whether
> > they
> > >> > need N times or 1 time after hibernation.  I only use
> > scheduleAtFixedRate() if
> > >> > I have something staying in sync with the passage of time.  I use
> > >> > scheduleWithFixedDelay() in all other cases because if the command
> > takes a
> > >> > long time, I don't need it to run right away.
> > >> >
> > >> >
> >
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledE
> > >> > xecutorService.html
> > >> >
> > >> > -Nathan
> > >> >
> > >> > -----Original Message-----
> > >> > From: [hidden email]
> > [mailto:[hidden email]
> > >> > [hidden email]] On Behalf Of Markus KARG
> > >> > Sent: Saturday, January 09, 2016 6:58 AM
> > >> > To: 'Carsten Schipke' <[hidden email]>
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > Carsten,
> > >> >
> > >> > the Windows API provides several different methods for timing. Some
> > of
> > >> > them are definitively able to fire at a particular point in time,
> > independent of
> > >> > any hibernation.
> > >> >
> > >> > In case a different OS won't have such a factility, there is a simple
> > fallback:
> > >> > Triggering events more often, checking the actual time (in pure Java),
> so
> > we
> > >> > find out whether to wait further, or whether the event is to be fired.
> > This,
> > >> > BTW, is the workaround applied by pure Java solutions currently,
> hence
> > what
> > >> > I'd like to get rid off by this feature request. :-)
> > >> >
> > >> > -Markus
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carsten Schipke [mailto:[hidden email]]
> > >> > Sent: Samstag, 9. Januar 2016 14:09
> > >> > To: Markus KARG
> > >> > Cc: [hidden email]
> > >> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling
> /
> > >> > Request for Comments
> > >> >
> > >> > sure, as I mentioned, I have never really had that requirement, it just
> > >> > sounded to me like many programmers could have many slightly
> > different
> > >> > requirements on such an API. I also don?t know what the Windows
> API
> > >> > offers in those regards / how its solved there, but if there is such a
> > widely
> > >> > accepted solution, then it surely would make sense as you say.
> > >> >
> > >> >
> > >> > > On Jan 9, 2016, at 21:04, Markus KARG <[hidden email]>
> > wrote:
> > >> > >
> > >> > > I think it should be up to the programmer (e. g. by passing a flag or
> > using
> > >> > different methods) whether he wants 10 events after missing those
> > while
> > >> > hibernation, or whether he wants the events to be collapsed into one
> > single
> > >> > event alternatively. BTW, I never said that the API must support an
> > absolute
> > >> > variant of repeated event schedulung. You could also simply provide
> an
> > >> > absolute variant of the "fire ONCE" method, and the mail application
> has
> > to
> > >> > reschedule inside of the event handler.
> > >> > >
> > >> > > Hooks are out of scope for my proposal, as they solve a different
> > problem
> > >> > and are working on a deeper level (the scheduler API could certainly
> > make
> > >> > use of such hooks). In case the Windows API for example would be
> able
> > to
> > >> > solve the problem for us (it is, BTW), why shouldn't we provide a Java
> > API
> > >> > wrapping that (without running into any rattail, as we simply offload)?
> > >> > >
> > >> > > -Markus
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Carsten Schipke [mailto:[hidden email]]
> > >> > > Sent: Samstag, 9. Januar 2016 11:02
> > >> > > To: Markus KARG
> > >> > > Cc: [hidden email]
> > >> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute
> Scheduling
> > /
> > >> > Request for Comments
> > >> > >
> > >> > > ?...or it will fire instantly after the end of hibernation ?? considering
> > your
> > >> > example of hourly/periodically checking mails, that would mean that
> the
> > >> > program checks your mailbox 10 times at once after 10h hibernation.
> > >> > > So the API would also need to know whether unfired events should
> > queue
> > >> > up over time. Sounds like a rattail pulling endlessly use cases &
> > requirements
> > >> > behind it.
> > >> > >
> > >> > > I for one never thought about using the JVM to schedule things that
> > live
> > >> > through hibernation or similar (not knowing the original intention of
> the
> > API).
> > >> > But I have also never built daemon-like desktop/client
> > applications/services.
> > >> > >
> > >> > > I guess in case of JVM, one could argue that specifications only apply
> > at
> > >> > runtime, and hibernation is interrupting that. Maybe it would be
> better
> > to
> > >> > provide hooks e.g. in the Runtime class to allow callbacks on pre-
> /post-
> > >> > hibernation, standby, signals etc. Then one could de/attach events
> > >> > accordingly.
> > >> > >
> > >> > >
> > >> > >> On Jan 9, 2016, at 17:28, Markus KARG <[hidden email]>
> > >> > wrote:
> > >> > >>
> > >> > >> The following requests comments on a Feature Proposal for
> > Absolute
> > >> > Scheduling.
> > >> > >>
> > >> > >> OpenJDK ticket JDK-8146527
> > (https://bugs.openjdk.java.net/browse/JDK-
> > >> > 8146527) describes the following case:
> > >> > >>
> > >> > >> * ScheduledExecutorService.schedule() is invoked to schedule
> firing
> > of an
> > >> > event "in one minute".
> > >> > >> * The laptop lid gets closed instantly after that, so hibernation will
> > occur,
> > >> > hence the JVM will suspend.
> > >> > >> * After thirty seconds of hibernation, the laptop lid gets openen, so
> > >> > hibernation will cancel and the JVM resumes.
> > >> > >> * Despite the expected result (one minute after start of program
> the
> > >> > event does occur), the event actually is delayed by the length of the
> > >> > hibernation phase, and happens 90 seconds after the program was
> > started.
> > >> > In the expectation of the end user, the event fired 30 seconds "too
> > late"!
> > >> > >>
> > >> > >> This is annoying to users and rather unexpected and astonishing for
> > >> > programmers literally following the words of the JavaDocs. Clearly the
> > >> > provided deadline is a relative value in the physical sense ("one
> minute
> > from
> > >> > now, independent of what 'now' is currently like"), but certainly what
> > the
> > >> > user actually expects it to work like is an absolute value in the physical
> > sense
> > >> > ("one minute from now, where 'now' is the current point on the time
> > axis of
> > >> > the Universe, hence unaffected by hibernation). Whether or not the
> > laptop
> > >> > was closed temporarily in the meantime plays no role to the
> expectation
> > of
> > >> > neither the end user nor the application provider.
> > >> > >>
> > >> > >> Unfortunately there is no other API that allows the application
> > vendor to
> > >> > define that the deadline it meant to be unaffected of hibernation.
> > Clearly
> > >> > this is a drawback to the Java platform, as many applications need such
> a
> > >> > behaviour (like "check my mails once per hour" - if you open your
> laptop
> > lid
> > >> > ONLY for a few minutes to see whether meanwhile new emails
> arrived
> > or not
> > >> > [like, BTW, some laptops are able to perform these days, even with
> the
> > lid
> > >> > closed, thanks to a BIOS timer] you won't receive any new emails ever
> > as
> > >> > "JVM" time progresses only be few minutes per day then).
> > >> > >>
> > >> > >> A solution could be the addition of a special variant of
> > >> > ScheduledExecutorService.schedule(absoluteInstant) which is
> > unaffected of
> > >> > any hibernation, and will fire either exactly at the absoluteInstant (in
> > case the
> > >> > laptop is not hibernating _currently_), or it will fire instantly after the
> > end of
> > >> > hibernation, in case the laptop was hibernating at absoluteInstant.
> > >> > >>
> > >> > >> There are two possible ways to reach this: Either there is an OS-
> > specific
> > >> > API that alrady provides exactly that behaviour, or the JVM needs to
> be
> > >> > informed every 'x' fractions of "discontinuous jvm time" to find out
> how
> > >> > much "continuous real world time" has advanced and whether a
> > scheduled
> > >> > event was missed meanwhile (which is the workaround such
> > applications
> > >> > have to perform on their own currently to workaround the problem).
> > The
> > >> > first is problematic due to changes in the implementations of the APIs
> > (e. g.
> > >> > Windows changed some APIs from "continuous time" to using
> > >> > "discontinuous time"), the second is complex in finding the optimal
> > value of
> > >> > 'x' (too low means high power consumption, too high means firing too
> > late
> > >> > after the deadline).
> > >> > >>
> > >> > >> Side note: To be unambiguous, the new deadline should possibly
> be
> > >> > typed as java.time.Instant, as that could never be misunderstood as
> > >> > "discontinous jvm time" inherently.
> > >> > >>
> > >> > >> What is your opinion on that?
> > >> > >>
> > >> > >> -Markus
> > >> > >> _______________________________________________
> > >> > >> Concurrency-interest mailing list
> > >> > >> [hidden email]
> > >> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Concurrency-interest mailing list
> > >> > [hidden email]
> > >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Concurrency-interest mailing list
> > >> > [hidden email]
> > >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >>
> > >>
> > >> _______________________________________________
> > >> Concurrency-interest mailing list
> > >> [hidden email]
> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > [hidden email]
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest