Hi Przemek,
Il 08/03/2009 3.26, Przemyslaw Czerpak ha scritto:
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.
Simply using your shell test you have to see running threads increase
from starting 4 to x (in mine case to 12), then when you create the stop
file activity will cease and threads have to come back to initial 4.
In previous modification threads stay at maximum reached until uhttpd ends.
In the above test 10 different processes simultaneously read three
different http pages served by uhttpd.
Ok now tested.
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.
Yes it is, but as you wrote I'm trying to make a prg that can be used on
other platforms, maybe based also on hbcurl.
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.
Yes, I see that listen() have a queue for incoming connection, but once
a connection is retrieved inside uhttpd it's uhttpd job to handle it.
But surely the main problem now is to understand if there are GPF points
that have to be found.
In any case, until now I got problems only on windows. Tests in Linux
seems to works correctly, but in my case I did tests only in a virtual
machine.
Best Regards
Francesco
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
