On Wed, 28 Jan 2009, Przemyslaw Czerpak wrote:
Hi,
> I suggest to ignore this problem until I'll not change structures used
> to hold static variables. The chance for GPF is rather small. The side
> effect of array preallocation added by Mindaugas is noticeable reduced
> number of memory reallocation when new statics are added so the risk is
> really small that the problem will be exploited. Of course it _MUST_ be
> fixed but it should not be critical during uHTTPd developing.
This problem should be eliminated by:
2009-02-02 11:02 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Here are the last points on my MT TODO list:
1. Tracelog is not MT safe. It's not a big problem for normal
applications because this code is disabled in standard builds and
enabled only on explicit user request during Harbour compilation
to debug some Harbour internals so it's rather for developers
only.
2. PROFILLER cannot collect information for each thread separately.
It's optional code disabled by default. Before we will touch it
please think how it should work for MT programs.
3. DEBUGGER: only main thread debugger can see the names of file wide
STATICs and have information about line numbers with good break
points. We should add code to share this information between threads.
4. hb_threadQuitRequest() can be ignored by thread in some cases
due to race condition. It may happen if thread will overwrite
request send by caller simultaneously, f.e. by its own BREAK.
I can resolve it but we can also leave it as is and document
such behavior as expected or even remove this function. Killing
other threads in such way is dangerous and can be used only
for some simple situation. It's much safer when user uses his
own mechanism to terminate treads in some safe for his code places.
5. We should check contrib code and eliminate non MT safe code
or document non MT safe functions.
6. Possible TODO:
- add CRITICAL {FUNCTION|PROCEDURE}
As you can see there is nothing critical in the above list what can
block MT programming.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
