> Le 28 déc. 2017 à 17:18, Richard Hipp <[email protected]> a écrit : > > There is one thread per connection in the parent process, which allows > the parent to manage multiple simultaneous incoming connections. As > each thread gets a complete HTTP request, it writes that request into > a temporary file, uses fossil_system() to invoke the "fossil http" > command to handle the request and store the reply into a second > temporary file, then the thread reads the reply and sends it back over > the wire. Finally, the two temporary files are deleted. > > The fork() approach is much nicer, but we don't have fork() on > windows. I'm open to suggests on better ways to do this.
Unless your intend is to be able to support thousands of simultaneous requests, there is few to earn in changing this scheme. The scaling limitation would be that spawning of sub-processes. Overcoming that is possible, but is a major redesign of the very clear and simple winhttp.c you currently have. I wouldn't loose precious time in that area. As pointed in my other message, the main culprit of occasional sluggish windows behaviour when fossil reaches out a windows fossil server is that the server inadvertently implements an IPv4-only listening socket while the client is dual-stacked. It can loose seconds (in the order of multiple times 10 or 20 seconds) per IPv6 connection attempt not answered by the remote server before finally trying an IPv4 address and succeeding its connection. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
