[
https://issues.apache.org/jira/browse/SIS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-76.
----------------------------------
> Remove (for now) the internal ThreadPoolExecutor
> ------------------------------------------------
>
> Key: SIS-76
> URL: https://issues.apache.org/jira/browse/SIS-76
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Utilities
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Minor
>
> SIS needs a thread for executing short tasks after some (potentially zero
> nanosecond) delay. This thread is reserved to internal SIS usage, mostly
> resources disposal. We tried to use the {{java.util.concurrent}} package in a
> previous version, especially {{ScheduledThreadPoolExecutor}}, but those
> executors seem more suitable to heavier tasks in applications controlling
> their own executor. Indeed, the Javadoc of the {{ForkJoinPool}} executor said
> "_Normally a single {{ForkJoinPool}} is used for all parallel task execution
> in a program or subsystem. Otherwise, use would not usually outweigh the
> construction and bookkeeping overhead of creating a large set of threads._"
> So we may be better to let users create their own executor, and potentially
> leverage it in SIS (this strategy is yet to be determined).
> It seems difficult to instantiate an executor for casual SIS use without
> wasting resources. For example {{ScheduledThreadPoolExecutor}} acts as a
> fixed-sized pool, thus forcing us to use only one thread if we don't want to
> waste resources (profiling shows that even a single thread has very low
> activity for the SIS tasks that we need to submit in background). The
> {{ThreadPoolExecutor}} super-class is more flexible but still have a quite
> aggressive policy on threads creation, and doesn't handle delayed tasks by
> itself.
> We could try to combine both worlds with a {{ThreadPoolExecutor}} using a
> {{DelayedQueue}}, but it forces us to declare a core pool size of 0 otherwise
> {{ThreadPoolExecutor}} tries to execute the tasks immediately without queuing
> them. Combined with the {{DelayedQueue}} characteristics (being an unbounded
> queue), this result in {{ThreadPoolExecutor}} never creating more than one
> thread (because it waits for the queue to reject a task before to create more
> threads than the pool size).
> Given that it seems difficult to configure {{(Scheduled)ThreadPoolExecutor}}
> in such a way that two or more threads are created only when really needed,
> given that using those thread pools seems an overkill when the pool size is
> fixed to one thread, given that our profiling has show very low activity for
> that single thread anyway, and given that we do not need cancellation and
> shutdown services for house keeping tasks since they are executed in a daemon
> thread, a more lightweight solution seems acceptable here. Se we could remove
> the internal SIS executor, use a single thread as we do for
> {{ReferenceQueueConsumer}}, and wait to see later if we need an executor.
> h2. Future evolution
> We may revert to an executor in a future SIS evolution if we happen to need
> an executor anyway. However it may be better to wait and see what are the
> executor needs. Setting up an executor implies choosing many arbitrary
> parameter values like the number of core threads, maximum threads, idle time,
> queue capacity, _etc._ Furthermore some platforms (e.g. MacOS) provide
> OS-specific implementations integrating well in their environment. We may
> want to let the user provides the executor of his choice, or we way want to
> have more profiling data for choosing an appropriate executor. But we would
> need to find some way to give priority to SIS tasks, since most of them are
> for releasing resources - in which case quick execution probably help the
> system to run faster.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
