On Sun, 08 Mar 2009, Francesco Saverio Giudice wrote:
Hi,
>>
>> 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.
OK, I also look at the code deeply and I've found that you have two
thread sets and threads in the second one are added dynamically if
necessary and then remove. I'm not sure it's good solution though
some time it can be usable. Anyhow it's still not safe because you
can send you can send termination signal to child thread which will
be suspended, then enter the cleanup thread which makes:
// Requesting to Running threads to quit (using -1 value)
AEVAL( s_aRunningThreads, {|| hb_mutexNotify( s_hmtxRunningThreads, -1 ) } )
// Requesting to Service threads to quit (using -1 value)
AEVAL( s_aServiceThreads, {|| hb_mutexNotify( s_hmtxServiceThreads, -1 ) } )
// waiting running threads to quit
AEVAL( s_aRunningThreads, {|h| hb_threadJoin( h ) } )
// waiting service threads to quit
AEVAL( s_aServiceThreads, {|h| hb_threadJoin( h ) } )
and in this moment the child thread will be resumed, and execute:
hb_aDel( s_aRunningThreads, nPos, TRUE )
or:
hb_aDel( s_aServiceThreads, nPos, TRUE )
It's race condition which have to be fixes.
> 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.
Or maybe HBTIP library is enough.
> 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.
I was afraid that the problem can be exploited only in Windows and
I think I know the reason. I used semaphore variables to emulate
conditional variables. It may work but only if windows keep one
strict restriction for them and always put threads in FIFO queue.
I know MS and it's probably not true. It should be for threads with
the same priority but Windows seems to temporary change priorities
for some threads, f.e. "to improve" interactive programs. It will
break current code. To resolve the problem I should use full POSIX
thread conditional variables emulation I added for OS2 builds also
in Windows.
I'll commit such modification in a while so please make some tests
in real Windows.
BTW my few notes:
1. In *nix build using GTXWC is not necessary. I suggest to simply
use default GTTRM GT driver. Not all user use xWindow.
2. hb_inetTimeOut() should be used in different way. There is a typo
in hb_inetDataReady() in second parameter I'll fix in a while and
I'll update this code. I also suggest to use bigger delay at least
in *nixes. Please verify my modifications.
3. the files in ./sessions directory can cause very serious performance
problems on some file systems due to huge amount of files in single
directory.
4. FILE_STOP is check only when there is no incomming connection so
I was not able to stop uhttpd server simulating big number of
concurrent connection. It should be check also after receiving
new connection at least once per few times.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
