On Sun, 08 Mar 2009, Francesco Saverio Giudice wrote:
Hi,
> I have to revert partially this code and corrected it, because with your
> changes s_aRunningThreads and s_aServiceThreads will never reduced in case
> of single thread end and leaving finished threads up and running.
I'm sorry but I do not understand the above answer yet.
Can you define more precisely the conditions which creates
any anomalies and how can I replicate them?
Probably I do not understand something in this code.
>> * reactivated hb_gcAll( .T. ) in the main loop for tests.
>> I made some tests with linux and current uhttpd works perfectly
>> without any problems with and without hb_gcAll( .t. ).
>> I haven't noticed any problems. I used this scripts to make
>> tests:
>> #!/bin/sh
>> function GT_UHTTPD()
>> {
>> while curl http://127.0.0.1:8082/ > /dev/null
>> do
>> if ! curl http://127.0.0.1:8082/serverstatus > /dev/null
>> then
>> exit
>> fi
>> # disable it if you want to increase traffic
>> if ! curl http://127.0.0.1:8082/info > /dev/null
>> then
>> exit
>> fi
>> if [ -f stop ]
>> then
>> exit
>> fi
>> done
>> }
>> for i in `seq 10`
>> do
>> GT_UHTTPD &>/dev/null &
>> done
>> wait
>> on three CPU machine. Please make some test with other systems.
> I'm testing your sample, but (not still tested) is this serialized or
> connections are submitted concurrently ?
In the above test 10 different processes simultaneously read three
different http pages served by uhttpd.
> I'm creating a multithread test that sends concurrent requests to pages
> with a sleep inside to simulate long time reply and increase number of
> threads needed to reply.
The above it's prefect test for concurrent access but if you will add
some other tests on .prg level then it can be used also in environment
which does not support *nix like shells. It should greatly help in testing
this code.
> In any cases uhttpd has to add threads (up to max number defined, after it
> will reply with a busy error) in case of no available threads, but it has
> to release them when no more necessary (to minimum number defined).
Not exactly. The concurrent queries are also buffered by the kernel in
waiting queue (see listen() parameters) so this limit cannot be defined
such precisely anyhow it should be unimportant for above test. We are
not checking how efficient uhttpd is but only if it has or not some
internal problems which may cause uhttpd/HVM code crash.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
