libeio EIO_STACKSIZE

[Konstantin Osipov]

* Marc Lehmann <schmorp at schmorp.de> [13/01/24 11:18]:

> While this is completely unrelated, this is wrong on so many levels:
> 
> 1. 64 bit pointers don't give you millions of stacks, they are a
>    requirement, but not sufficient. For example, on very common
>    amd64 hardware your address space is enough for ~16 million
>    stacks of 8MB size, which is a far cry from hundreds of
>    millions. And that's already quite generous for 64 bit
>    architectures.
> 2. If it truly were virtual, then you could use a much smaller
>    stack space.  The fact that you get crashes indicates that
>    the stack is "physically" too small, nothing cares about
>    virtual size.
> 3. This is only true when overcommitting 100%, which is quite
>    uncommon.
> 4. It disregards the memory used for page tables - for your
>    hundreds of millions of threads you would require gigabytes of
>    ram without counting thew actual stack itself.

I agree my argument was oversimplifying the problem.
At the same time I have yet to see a reasonable
application that is using more than a hundred of thousands of
threads. Last time I saw such a beast was in the previous
decade, and then again it was Solaris 9 with m:n threading.

On a practical note, a possible solution to the issue is to add a
macro similar to EV_MULTIPLICITY to libeio.

If EIO_MULTIPLICITY is defined, every eio_ function will require 
a reference to a thread pool as its first argument.

This would allow me to keep using libeio for gethostbyname() &
friends, those who want to use gethostbyname() *and* file I/O
won't shoot themselves in the foot and use two thread pools, and
those who don't know and don't want to know anything about the
issue will keep using libeio the old way.

To close the topic of stack size in relation to Tarantool, since
we have an (ugly) habit of adding most third-party libraries to
our revision control, for us the problem (for now) got solved with
a two-line patch to xthread.h, which makes it work according to,
the old manual.

In future, we may indeed make `a good design decision` and use
another library for a thread pool, or carve out the thread pool
from libeio (more likely), or do something else. 

-- 
http://tarantool.org - an efficient, extensible in-memory data store