--- In Firebird-Architect@yahoogroups.com, Alex Peshkov <pes@...> wrote:

>
> Jim Starkey:
>
> Technology of threads control, implemented by Borland in interbase, was
> 'slightly' not-traditional - it is voluntary threads switching
> (something similar to cooperative multi-tasking in windows3.1), and

only

> in vulcan that voluntarism has gone. Windows thread scheduler treats a
> call to WaitForMultipleObjects, performed by voluntary thread scheduler
> of firebird (which does not differ from interbase), as "thread is
> inactive and it's priority should be increased". In fact this is active
> thread, which is ready to run, but is delayed by voluntary thread
> scheduler. Therefore threads, which were actually waiting for

something,

> do not have priority higher compared with threads, actively running
> under control of voluntary firebird thread scheduler. As a result,

under

> high loads firebird 1.0 server might did not respond for minutes (!) to
> trivial queries. Should mention, that I've never seen such effects in
> linux, though this may mean that under normal circumstances windows
> thread scheduler does it's job better.
>
> Switching of priorities, mentioned initially, in most cases makes
> firebird server much more responsive. And, answering your question,

what

> you see in firebird.conf is a typo - inactive thread certainly gets
> higher priority. This parameter should be gone in firebird 3 (after
> vulcan integration).
>

A typo that Helen Borrie copied into her book as well then, unfortunately.
But assuming this is a typo, how can we explain the fact that when I
increase the value of this parameter from 100 ms to 400 ms, it gets
much worse? I then expect my active threads will be turned to low
priority later, giving them more time to finish (which should be well
possible within that timeframe). When a time-taking query is running
at the same time, the performance of the small jobs drops
dramatically. As if the priority was low already...

Hans