PC Toledo

Código: Selecionar todos

https://sourceforge.net/forum/message.php?msg_id=4834626
By: alkresin

There are two threads already, see the latest Changelog.
One thread accepts connections, waits for and reads all incoming requests and
replies to those of them, which doesn't demand database access. Other thread
handles all database related requests. Such model is implemented, because Harbour
doesn't support mt yet and it isn't possible to have few threads, working with
Harbour's stack, VM, RDD - so the second thread only works with all these, while
the first uses pure C ( not the Harbour RTL ) code.

Thus, handling of any database request ( independently of which dbf, the same
or not ) is performed sequentially, one after another. The time of server answer
doesn't depend on which dbf is used by different users. Of course, if one client
program will, for example, reindex a huge dbf, all other clients will wait for
a remarkable time; if there is usual activity - skipping, seeking, updating
records, there will not be visible delay. I've run ~20 client test programs,
each of them opens ~30 dbfs and once in a second performs some action ( skipping
20 records, close/open table, etc. ) and all this activity results in 1-2% CPU
loading on a server ( Pentium IV, 3000 GHz ) and ~5% increasing the time of
a huge test ( updating, skipping dbf ).

Anyhow, I plan to introduce separate processes, which will handle most time
consuming requests, such as indexing.