Subject | RE: [IB-Architect] Connection resources, classic vs. SS |
---|---|
Author | Jim Starkey |
Post date | 2001-02-27T15:10:23Z |
At 11:02 PM 2/26/01 -0400, Claudio Valderrama C. wrote:
author, I was the first to condemn it.
To decrease the threading granuality the synchronization mechanism
decentralization. The problem is that in C, particularly with the
current exception handling mechanism, making sure all synchronization
locks are released through all possible returns from a function is
problematic at best. The obvious solution is the C++ object
destructor mechanism and C++ exceptions. Cutting the code base
over is a non-trivial but essential undertaking.
Jim Starkey
> I've seen a daunting structure that's used to keep track on how much aThe Firebird engine has essentially one mutex. As the original
>request has been run. If the time tracked is more than a threshold, the
>current execution gives up in favor of another request being executed. In
>this context, "give up" is to pass the control to a peer thread, not to
>abort the thread that reached the threshold.
> This manual handling of threads works at the same time than the thread
>scheduling done by the operating system. Is this observation correct? Could
>we get rid of such mechanism in the future?
author, I was the first to condemn it.
To decrease the threading granuality the synchronization mechanism
decentralization. The problem is that in C, particularly with the
current exception handling mechanism, making sure all synchronization
locks are released through all possible returns from a function is
problematic at best. The obvious solution is the C++ object
destructor mechanism and C++ exceptions. Cutting the code base
over is a non-trivial but essential undertaking.
Jim Starkey