-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Add delay in @Background #525
Add delay in @Background #525
Conversation
|
Hi, Thank you for contributing this. However, I don't think you need to use a Handler this. The JDK already has the needed bits : http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html |
|
I didn't know about |
|
I switched from |
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.
The core pool size set to 1, which AFAIK means the maximum number of threads on this executor will always 1. As a consequence, you'll never get two delayed tasks to run concurrently. Is that on purpose ? @Background has always had a parallel behavior, if we want serial behavior which should make a clear distinction.
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.
I didn't know which value to set here. Maybe a big one (ex: Integer.MAX_VALUE) or maybe we should create a ScheduledExecutorService each time we call executeDelayed ? Do you know the effect of a value of 0 for the core pool size ? It's not said in the java doc and it doesn't seem to rise an exception.
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 may be a good thing to let the user defines how many threads he wants because this is typically a parameter that changes according to the needs.
Maybe with another optional parameter in the @Background annotation. If the user doesn't fill this parameter, assign a default value to 5 for the corePoolSize.
What do you think about this idea?
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.
I don't think it's a good idea as it means each @Background could be responsible of the creation of a thread pool. That could cause a performance issue, and it could be hard to understand from a developer point of view.
I would prefer to define a value. Something like that :
- [Runtime.availableProcessors()](http://developer.android.com/reference/java/lang/Runtime.html#availableProcessors(\)) * 2
- Math.ceil([Runtime.availableProcessors()](http://developer.android.com/reference/java/lang/Runtime.html#availableProcessors%28%29%29 * 1.5d)
What do you think ?
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.
I think Mathieu is right. The more so as a developper will be able to change the ScheduledExecutorService using the static method of BackgroundExecutor. Regarding the value to set, I have no idea.
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.
👍
|
I changed the |
|
Great work 👍 |
Hi,
This commit is a solution for the issue #332.
Because the class
Executordoes not have a methodexecuteDelayed, I use aHandlertopostDelayedthe call to the methodexecute.Comments are very welcome.