What is the thread pool used for?

[psznm]

What is the thread pool used for, and will it be used by Io vtable? I am wondering because I wish to have multiple threads, and have zio instance per thread. I would prefer if zio instance didn't need additional threads, but I also do not want the zio's event loop to be blocked.

[lalinsky]

The thread pool is essential for operations that do not have any native async API. For example, there is no way to asynchronously read a file on macOS/BSDs. So the read operations go through the thread pool. It's the sam model that e.g. libuv uses. You can avoid the thread on io_uring, but on every other system, it's not possible to get rid of it without blocking the event loop.

I could make it possible to reuse a single thread pool for multiple instances, if you want to use it that way.

For the edited out userdata question, all operations except for task spawning work based on the current scope. If you are running from within a task, they use the event loop. Otherwise they use blocking operation. So most vtable functions simply ignore the userdata. Operations will be submitted to the event loop where the task runs, irrespective of what io param you pass.

And one more thing, if yiu want multiple instances, you need to create them in their corresponding threads. They can't move between threads, so you can't create 4 instances in the main thread and the pass them to the extra threads.

[psznm]

The thread pool is essential for operations that do not have any native async API. For example, there is no way to asynchronously read a file on macOS/BSDs. So the read operations go through the thread pool. It's the sam model that e.g. libuv uses. You can avoid the thread on io_uring, but on every other system, it's not possible to get rid of it without blocking the event loop.

I could make it possible to reuse a single thread pool for multiple instances, if you want to use it that way.

I would, if I wasn't using exclusively io_uring. But since I do only use linux, I understand I don't need the extra threads anyway so not being able to share the thread pools doesn't bother me specifically. That pretty much answers my question. Thanks!

For the edited out userdata question, all operations except for task spawning work based on the current scope. If you are running from within a task, they use the event loop. Otherwise they use blocking operation. So most vtable functions simply ignore the userdata. Operations will be submitted to the event loop where the task runs, irrespective of what io param you pass.

I was playing around with this today and I have example where I can simply create another zio instance to test out the thing I was asking (just don't have the example available to me until I return to work), which is why i removed that question. I am still not quite sure whether passing commands via queue between two threads with two different zio instances will work, but with "Operations will be submitted to the event loop where the task runs" I would say it won't. I am not sure if queue.put is considered operation or not, and whether it applies to it. Will test it out tomorrow - I still believe it will just work out.

And one more thing, if yiu want multiple instances, you need to create them in their corresponding threads. They can't move between threads, so you can't create 4 instances in the main thread and the pass them to the extra threads.

Yes, that is fine, I am already structuring my small programs and experiments around that fact.

[psznm]

Actually "except for task spawning " this interests me. Does that mean I should be able to run zio_io.async or zio_io.concurrent from another thread to put that on the thread with zio straight into the event loop? I believe I tried that without success. It is possible I made some other mistake. If that was possible, that would be a game changer though. That would also completely solve the use-case I had for the queues between zio threads.

[lalinsky]

Actually "except for task spawning " this interests me. Does that mean I should be able to run zio_io.async or zio_io.concurrent from another thread to put that on the thread with zio straight into the event loop?

Yes, that's should work. What async/concurrent do is: 1) allocate the task metadata 2) allocate the task stack 3) schedule it to an executor on the target runtime. All those operations are thread-safe. So you can do zio_io.concurrent from another thread and spawn the task into the zio_io's event loop.

[lalinsky]

But since I do only use linux, I understand I don't need the extra threads anyway so not being able to share the thread pools doesn't bother me specifically.

After #458 is merged, you can disable the thread pool by setting .min_threads = 0, .max_threads = 0. That will simulate the -fsingle-threaded behavior.