-
Notifications
You must be signed in to change notification settings - Fork 578
Introduced ScheduledExecutorServiceTimer #51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this import is redundant.
|
Thanks. I'm pulling this internally, and it should appear here shortly (after review there) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this remove was anyway redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like this isn't redundant. the executor service will not actually proactively remove the runnable from its queues if .remove isn't called
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that ScheduledThreadPoolExecutor is the only implementation in the Java standard library of this, the simplest thing would be to just use that for the dependency instead, even if that's a bit icky. Some other alternatives are:
- Some sort of marker trait that allows you to remove runnables
- Wrap the scheduled executor service so that it does the right things on
cancel.
Sadly, both of these introduce complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, jdk7 provides a method on ScheduledThreadPoolExecutor, setRemoveOnCancelPolicy(boolean), that properly handles cancellation.
|
Note that I didn't actually change any logic, just split ScheduledThreadPoolTimer into two separate classes. Marius, anything I can do to help or have you got this? |
|
It did change, unfortunately: see my line comment above. The |
|
Hmm. I must have missed that last commit by @jpinner somehow. Sorry for that. Taking a Note, also, that returns instances of I'm going to commit a further fix which calls this method from the new |
…nd documenting why this is important for ScheduledExecutorServiceTimer
|
Unfortunately this was introduced in JDK7, and we still need to be compatible with JDK6. |
|
Oh crap. The last resort would be to not have It's either that, or do some What do you say? |
|
I like the idea of just refactoring some of it out via a mixin so you can reuse that code. |
…merSupport, which provides a hook to be called on task cancellation. ScheduledThreadPoolTimer extends this hook and being intimately familiar with ScheduledThreadPoolExecutor, removes the runnable from the executor's queue to prevent retention of tasks with long delay
|
Thanks. Pulling this internally & it should appear here shortly. |
|
I changed the support class to be a mixin (with self-types) and made underlying protected. |
|
This is now in master, closing |
Remove scala-xml, unused
ScheduledThreadPoolTimer doesn't allow creating a Timer instance around a pre-existing ScheduledExecutorService.
My fix introduces a new class, ScheduledExecutorServiceTimer, which is spawned from ScheduledThreadPoolTimer. The latter now extends the former and only handles the construction of a ThreadPoolScheduler based on the constructor arguments, passing the resulting ScheduledExecutorService to the super constructor.