westonpace commented on issue #35176:
URL: https://github.com/apache/arrow/issues/35176#issuecomment-1516694631
> One thought, but if ThreadPool was to wrap a singleton SerialExecutor if
ARROW_DISABLE_THREADING was set, things might just work well enough for a first
attempt at an unthreaded build? I don't know whether there'd be any deadlocks
in i/o vs compute tasks though?
If everything is tasks and a single `SerialExecutor` is used then it should
be ok (e.g. there shouldn't be deadlocks). It will just be very slow when
doing I/O because we will be sitting there waiting on I/O with our one thread
while the CPU sits completely idle.
That being said, I'm sure there are a few bugs / things that will need to be
converted.
However, I'm not sure we can just wrap the global thread pools with a serial
executor. The challenge with the serial executor is that it has to co-opt the
calling thread. This means we create the executor when the call starts.
```
void ReadTable() {
# Where DoReadTable is a function returning a Future
# Note, we are not calling here, but passing it as a parameter
RunInSerialExecutor(DoReadTable);
}
```
However, if we are combining I/O and CPU into a single pool...then it should
be possible to create a special serial executor that creates a serial executor
when a task is first submitted.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
