JDK-8146527: Absolute Scheduling / Request for Comments

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

JDK-8146527: Absolute Scheduling / Request for Comments

Markus KARG

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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Schipke
“...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
Reply | Threaded
Open this post in threaded view
|

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

Markus KARG
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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Schipke
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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Schipke
In reply to this post by Markus KARG
That is if it would be portable - utilising Windows API would require similar facilities on all supported OS’s.

> 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
Reply | Threaded
Open this post in threaded view
|

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

Markus KARG
In reply to this post by Carsten Schipke
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
Reply | Threaded
Open this post in threaded view
|

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

Nathan and Ila Reynolds
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/ScheduledExecutorService.html

-Nathan

-----Original Message-----
From: [hidden email] [mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

Markus KARG
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/ScheduledExecutorService.html

-Nathan

-----Original Message-----
From: [hidden email] [mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

Nathan and Ila Reynolds
Before this email chain, I hadn't thought about hibernation and its impact.  After I read through the email chain, I understood what you just summarized.  I then stated my expectations of the APIs.

Hence, I don't expect new APIs to come out of this.  I expect the existing APIs to be "corrected".

On the side, if you want to overload the methods which accept Duration and Instant parameters, I would be grateful.  I have already implemented such methods for my thread pools.  In fact, my implementation of the existing APIs forward the calls to my Duration and Instant methods.  I found this made the implementation of the overall thread pool much easier.

-Nathan

-----Original Message-----
From: Markus KARG [mailto:[hidden email]]
Sent: Saturday, January 09, 2016 10: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/ScheduledExecutorService.html

-Nathan

-----Original Message-----
From: [hidden email] [mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes-6
In reply to this post by Markus KARG
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
Reply | Threaded
Open this post in threaded view
|

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

Joe Bowbeer
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
Reply | Threaded
Open this post in threaded view
|

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

Alex Otenko
In reply to this post by Nathan and Ila Reynolds
I would expect these to be case-specific.

The flow of time is different in different frames of reference. Mailer wants it to be tied to the frame of reference coinciding with mail server (which is in the same frame as Greenwich), Sudoku game wants it tied to the frame of reference coinciding with Sudoku process space - it doesn’t want to count time towards the score whilst the game is not in the foreground.

It would be nice to have a replaceable clock, or the source of time for individual condvars.

Alex

> On 9 Jan 2016, at 17:18, Nathan & Ila Reynolds <[hidden email]> wrote:
>
> 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/ScheduledExecutorService.html
>
> -Nathan
>
> -----Original Message-----
> From: [hidden email] [mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes-6
In reply to this post by Joe Bowbeer

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]] 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 dont 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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Schipke
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]] 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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes-6
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
Reply | Threaded
Open this post in threaded view
|

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

Carsten Schipke
I am not talking about your specific programming style or whatever. I am talking about the JVM & Java language representing a portable runtime environment & framework that should provide consistent facilities to developers across all its supported underlying platforms.
And in many aspects, domains & ways, developers do very much try to exploit that portability the same methodologies across platforms - as far as they are allowed to.. I am talking about that “allowed to”.

I am definitely not writing any code nowadays that looks like 20 year old java applets or anything 20 year old for that matter.

Why wouldn’t you want to allow Java developers to write one email client for desktop & mobile (see Windows 10 & .NET) - just for sake of prior given example?


> On Jan 10, 2016, at 12:34, David Holmes <[hidden email]> wrote:
>
> 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
Reply | Threaded
Open this post in threaded view
|

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

Markus KARG
In reply to this post by David Holmes-6
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]] 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
Reply | Threaded
Open this post in threaded view
|

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

Andrew Haley
In reply to this post by David Holmes-6
On 10/01/16 03:07, David Holmes 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.

For servers it is ever more important because of virtualization, where
entire VMs will be suspended, migrated across the cloud, etc.  I think
that you probably do not want a lot of tasks all firing up when a VM
is restarted.

Andrew.

_______________________________________________
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

David Holmes-6
In reply to this post by Alex Otenko
I think Alex hits the nail on the head here. For these API's to work "correctly" in these difference contexts we have to make "time" an explicit part of the API and in particular we do need a notion of different Clocks that represent different kinds of "time". The Real-time Specification for Java did try to go down this path but ran into serious practical limitations - if the operating system doesn't support different kinds of clocks and the API's they expose don't allow control of the clocks involved, then implementing such abstractions in an efficient and practical way is exceedingly difficult, to say the least.

David
-------

> -----Original Message-----
> From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of Alex Otenko
> Sent: Sunday, January 10, 2016 12:04 PM
> To: Nathan & Ila Reynolds <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> I would expect these to be case-specific.
>
> The flow of time is different in different frames of reference. Mailer wants it
> to be tied to the frame of reference coinciding with mail server (which is in
> the same frame as Greenwich), Sudoku game wants it tied to the frame of
> reference coinciding with Sudoku process space - it doesn�t want to count
> time towards the score whilst the game is not in the foreground.
>
> It would be nice to have a replaceable clock, or the source of time for
> individual condvars.
>
> Alex
>
> > On 9 Jan 2016, at 17:18, Nathan & Ila Reynolds <[hidden email]>
> wrote:
> >
> > 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
Reply | Threaded
Open this post in threaded view
|

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

Markus KARG
In reply to this post by Andrew Haley
It depends on the use case, so the application programmer should decide
whether he wants coalesced events, an event storm, or the current behaviour
(delayed).

-Markus

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andrew
Haley
Sent: Sonntag, 10. Januar 2016 20:11
To: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
Request for Comments

On 10/01/16 03:07, David Holmes 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.

For servers it is ever more important because of virtualization, where
entire VMs will be suspended, migrated across the cloud, etc.  I think
that you probably do not want a lot of tasks all firing up when a VM
is restarted.

Andrew.

_______________________________________________
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
12