select.select() socket limit affecting EMANE node scalability; epoll-based replacement fails silently

[Noonmor]

I am currently working with EMANE on a Linux-based environment and testing its ability to scale across many nodes. While attempting to launch a large number of EMANE nodes, I encountered unexpected behavior.

When the number of EMANE nodes exceeds a certain threshold, the system appears to stop responding correctly — nodes do not start or communicate。
Upon reviewing the Python shell interface (specifically controlportclient.py), I noticed the use of the following pattern:
readable, _, _ = select.select([self._sock, self._read], [], [])
As select.select() has a known file descriptor limit (typically 1024 on Linux), this may explain why scalability is hindered.

To address this, I replaced select.select() with select.epoll() as follows:
epoll = select.epoll()
epoll.register(self._sock.fileno(), select.EPOLLIN)
epoll.register(self._read.fileno(), select.EPOLLIN)

for fileno, event in epoll.poll():
if fileno == self._sock.fileno():
# handle socket
elif fileno == self._read.fileno():
# handle wakeup
However, after making this change, EMANE no longer starts nodes correctly. The script runs without throwing any exceptions, but the system seems non-functional — no messages are sent or received.

Questions：
Is there an official or tested upper limit to the number of EMANE nodes that can be started concurrently?
Has the use of epoll or selectors been considered or tested for high-scale deployments?
Could there be specific assumptions in EMANE that depend on select() behavior (e.g., blocking characteristics or fd readiness) that cause silent failure with epoll?

Any insights or recommendations would be greatly appreciated. Thank you for your continued support of this powerful framework!
Best regards！