On Wed, 29 Aug 2001, Jim Jagielski wrote:
> recall that the current code *defaults* to NONE (basically, if no
> other method is compiled in) and will allow that option to be used
> (but will post a warning unless MULTITHREAD is defined). So we're
> even *safer* than the current such that if none are compiled in,
> we don't start.
The reason the current 1.3 non-MULTITHREAD code complains if it
doesn't know what method works for serialized accepts is because
they are _REQUIRED_ for things to work properly. Not having them is
an indication that the port does not work correctly.
>
> Basically the patch creates a set method based on that, and *allows* it to
> be compiled in if desired. Nothing more. I'd like more people
> to test the OS X implementation out, because that's the only one
> so far that I've seen that appears to work with some limited
> stress testing. And if we remove that from the Darwin case, so be it.
There is nothing to test. Using the 1.3 process based model, you need
serialized accepts if you have multiple listening sockets. Period.
Adding an option to disable that simply doesn't make any sense. "appears
to work" is irrelevant when you are dealing with race conditions. We
went through all the reasons why it is needed when it was added in the
first place, it wasn't just added on a whim.
What your patch does is make it appear legitimate to not use any accept
mutex in the multiple listener case on some non-MULTITHREAD platforms
on 1.3. That is not right.
