Skip to content
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

Develop kind of an async work scheduler for internal yielding tasks #5544

Open
Gerold103 opened this issue Nov 20, 2020 · 1 comment
Open
Labels
app feature A new functionality refactoring Code refactoring
Milestone

Comments

@Gerold103
Copy link
Collaborator

The problem: some systems have async work to do, which may yield. They don't want or simply can't do the work right away. For example, can be called via FFI, or want to collect a batch of such requests and merge them into one, or it is simply not urgent. All the listed cases I have dealt personally with. To solve it we usually introduce a new fiber, which belongs to a system and does the work. But in the end such fibers turn into kind of a local scheduler, which takes async tasks and executes them.

As a result, we re-invent this async tasks scheduler again and again, and keep multiple fibers for it. Just now we already have raft fiber, swim fiber, fiber for Lua to perform yielding GC (see fiber._internal.schedule_task).

This re-inventing leads to stepping on the same bugs, and having more fibers than needed, which also are sleeping most of the time.

Would be good if we could schedule work asynchronously without creating a new fiber and inventing a scheduler. For instance, reuse tx_fiber_pool somehow. Make it possible to push arbitrary tasks to it. Not only via IProto. Or implement a new system.

I know that we have fibers exactly for this, and they are "lightweight", except that they actually are not. Each fiber costs kilobytes or megabytes of stack memory, must be managed/joined/cancelled by the owner system, and it costs time to re-invent it again and again.

For this scheduler would be cool to implement kind of tasks, which are even more light than a fiber. And where we could push them from all the systems inside Tarantool.

@NeraverinTarantool
Copy link

Moved this one to wishlist - we have no plans for this issues in the nearest future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app feature A new functionality refactoring Code refactoring
Projects
None yet
Development

No branches or pull requests

5 participants