Dlux <[EMAIL PROTECTED]> writes:
>| I've deemed to be "too complex".) (Also note that I'm not a
>| database
>| guru, so please bear with me, and don't ask me to write the code
>| :-)
>
>Implementing threads must be done in a very clever way. It may be
>put in a shared library (mutex handling code, locking, etc.), but I
>think there are more clevery guys out there who are more competent
>in this, and I think it is covered with some other RFCs...
If amazingly clever threads handling is a requirement of this RFC
then it is probably doomed. Multi-processing needs detailed explicit
specifications to be done right - not vague requests.
>
>I also don't like the overhead, that's why I made the "simple" mode
>default (look at the "use transaction" pragma again...). This means
>NO overhead,
Not none, perhaps minimal ;-) - it has at least got to be looking
at something pragma can set.
>no locking between threads: this can be used in
>single-thread or multi-process environment. Other modes CAN switch
>on locking functions, but this is not default! If you implement that
>intelligently (separated .so for the thread handling), then it means
>minimal overhead (some more callback call, and that's all).
I would need to understand just where the thread hooks need to go.
So far my non-detailed reading suggests that the hooks are pretty
fundamental.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
