On 25/08/2025 10.51, Manos Pitsidianakis wrote:
On Mon, Aug 25, 2025 at 11:47 AM Thomas Huth <th...@redhat.com> wrote:
On 25/08/2025 09.30, Manos Pitsidianakis wrote:
On Thu, Aug 21, 2025 at 12:49 PM Thomas Huth <th...@redhat.com> wrote:
From: Thomas Huth <th...@redhat.com>
Currently, we have one lock that is held while a test is looking for
free ports. However, we are also using different ranges for looking
for free ports nowadays (PORTS_START is based on the PID of the process),
so instead of using only one lock, we should rather use a lock per
range instead. This should help to allow running more tests in parallel.
While we're at it, also create the lock files without executable bit
(mode is 0o777 by default).
(Unrelated to this patch but the file itself)
Hm. AF_INET supports binding to port 0 to connect to any available
port (see man 7 ip). Is this not portable?
No clue ... but in that case, we'd need to go back to only use one lock for
all tests that are running in parallel, so it might cause some more contention?
IIUC there would be no need for locking, since the kernel would return
a free port for each process.
That only works within a process, doesn't it? The problem here is that the
test itself does not open the port, it just first needs to figure out a free
port that will be used later.
The test then launches QEMU with that port number, which will then open this
port. Then the test connects to that port number (which it must know) to
interact with QEMU.
If QEMU is using port 0 for that, the test might not have a way to retrieve
the final port number from QEMU in all cases.
Thomas
