In the case of using q3map2 with 'build monitoring', the output of
q3map2 was being written twice, once for the logs received through the
'watchbsp' net connection and once as the fork/subprocess that actually
runs q3map2 was using the same stdout file descriptor as
netradiant-custom itself.
In order to prevent this, we redirect stdout/stderr to /dev/null in case
we use q3map2 with build monitoring for the subprocess and rely on the
received logs, which also get written to netradiant-custom's QT console.
differences were marginal between:
libs/l_net/l_net_berkley.c
libs/l_net/l_net_wins.c
now both platforms exist unified in a single file with ifdefs:
libs/l_net/l_net_wins.c
All of these were now unused and pertained primarily to finding out the
host's IP address via UDP broadcast (WINS_MyAddress), which was removed
in a previous commit.
As part of `l_net` there's currently code where a UDP socket is created
just to get the host's IP address, which is then stored and can be
retrieved via the above 2 functions.
`Net_MyAddress` is a shim around `WINS_MyAddress`, and was never used.
`WINS_MyAddress` was only used when `_DEBUG` flag is enabled at build
time to debug-print "the" IP address to the console.
Being that users never saw this message to begin with, it seems safe to
assume today that developers know themselves how to determine "the" IP
Address of their hosts without the need for this being built into
radiant.
This commit removes both functions, along with the UDP socket creation
code.
This also fixes a standing issue that these UDP sockets were never
closed and each build invocation accumulated lingering unconnected UDP
sockets.
Currently on Linux when building maps with `Build Process Monitoring`
enabled, there is a high chance that the build won't start, throwing the
following failure instead:
> Failed to get a listening socket on port 39000.
> Try running with Build monitoring disabled if you can't fix this.
This error occurs when Radiant attempts to re-bind the 39000 TCP socket
in `libs/l_net/l_net_berkley.c`.
It does not look to be a timing issue, as Radiant seems to correctly
order the steps of attempting to close the 39000 TCP socket connection
before recreating it again.
---
The following commit resolves this issue in the following ways:
Firstly the socket option `SO_REUSEADDR` is used to allow new sockets to
rebind to an address that is already in use.
Secondly sockets are now shutdown more cleanly via `shutdown` using
`SHUT_RDWR`, which immediately aborts standing/queued communication.
Merely closing a socket on Linux does apparently not "invalidate" the
"socket cache", and can therefore disallow rebinding the same address,
even despite using `SO_REUSEADDR`.
As such both changes are required in tandem to resolve the issue.
conditions fulfilled:
string pointer is always functional, hence no flow conditions needed
move is fully efficient
moving to different program dynamic module works (no dependency on static vars)
QTimer was getting new connections added w/o removing existing ones; fix the same in FreezePointer
zero check is seemingly not needed now; zeros spam was caused by this QTimer misuse
Garux
Willi Schinmeyer
Vorschreibung