At 11:29 AM 12/20/00 -0500, Ann W. Harrison wrote:

>At 04:03 PM 12/20/2000 +0300, Dmitry Kuzmenko wrote:
>
>>I'm not sure, it must be tested. I remember that in some IB version
>>all queries in different processes were executing serially, i.e. next query
>>won't execute until current is finished.
>
>Hmmm. The V2.0 TCP/IP server was like that. It made people mad,
>so we built pseudo-threading in 1987.
>

That would certainly have mad people mad, but that wasn't what we
did, dear spouse.

Engine execution is driver by an abomination called looper (see exe.c)
that performs threaded execution of the compiled statement tree. When
looper executes a statement that stalls a request, most notably
"blr_send" or "blr_receive", to returns to the client (in this case
the remote server) pending a matching client call isc_receive or
isc_send. At that point the remote server can and does switch
users.

So the unit was the request but the time between stall points.
If the request was to count the records in the table, the
count was non-interruptable. If the request was to fetch
all the records, it was interrupable.

Looper is an artifact of non-threaded environments. Looper started
a little ughly and has been hacked into a truely dreadful shambles
over the years. If Firebird were to recogize that threads are
here to stay, looper could be consigned to the scrap heap of history
to be replaced by nice, clean, encapsulated, polymorphic objects,
reducing the size, complexity, ughliness of the engine while
simultaneously increasing the performance. Less code, faster
code, more maintainable code; good stuff.

Jim Starkey