On Tue, 31 Jul 2012, Joe Mason wrote:

> I've found out how to run sws with the --fork option by calling "runtests.pl
> -f". But when I do that, several copies of sws are left running after
> runtests.pl finishes (so if I run runtests.pl again without killing them, it
> complains the ports are already in use).

Yeah, I did the fork option once just to be able to do some testing with a
large amount of connections (back when I created the multi_socket API). It was
never used in the test suite "properly" so if we need to have something like
that used, we need to add support for it.

> Is it a good idea to add code to runtests.pl to kill off all forked copies
> of sws that it started when it exists? (Or is there already a way to do
> this that I'm just missing?)

If we need to have a server running that accepts multiple connections
simultaneously, then using the --fork option might be a good idea.
Alternatively, we make the server just handle more connections in the same
process.

It probably make sense to make the sws server able to run with this option
always instead for just a specific test case as otherwise we need to shut down
and restart the sws server for the specific tests that need --fork.

> The reason I want it right now is because I wrote a test of NTLM auth, and
> found that because NTLM is connection oriented, curl will only reuse the
> same connection for requests with the exact same NTLM paramters. If you try
> to make two NTLM requests to the same host but with different usernames or
> passwords, curl will use a separate connection for each. Which is fine, but
> without the --fork option to sws, the test suite only listens on one
> connection at a time. With --fork, my new test seems to work.

Ah yes, makes sense. If we really need to have more than one conection to the
server up, then we need to make the server handle it I'd say!

> It seems to me that curl needs a lot more tests that exercise the mapping of
> requests to connections (especially as we start improving pipelining) so
> it's important for the test server to support multiple connections. So
> --fork should be well supported by the test suite. But the code is full of
> comments that say things like, "This is NOT what you wanna do without
> knowing exactly why and for what," and that --fork is for, "if you feel wild
> and crazy and want to setup some more exotic tests".

Right. I think I added those comments mostly because of what you already found
out: that the test suite isn't yet modified to actually work with it. It makes
the --fork option mostly usable only for custom special tests. I don't think a
forking http server in particular needs a lof of magic to get working.

> Ideally the server would support requests from multiple connections by
> default, so that the test authors wouldn't have to add "fork" keywords in a
> cargo-cult like way when writing tests that happen to create more than one
> connection. What would be the implications of turning --fork mode on by
> default for the test suite?

We might need to consider how the processes log stuff so that the different
children don't just race it all out to the same stream and create a mess.
Besides that, I can't think of many problems other than that we need to make
sure to kill off all child processes properly on exit.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html