#1 2011-07-12 10:39:37

migajek
Member
Registered: 2010-10-01
Posts: 89

THttpServerGeneric - threading, related to TSQLRestServer

Hi,
if I understood the code & docs properly, the instance of TSQLRestServer I'm exposing through TSQLite3HttpServer might be used in context of several threads (is thread pooling implemented for this?). If I'm correct, do I have to make sure TSQLRestServer callbacks are thread-safe, or are they synchronized by http thread?

Offline

#2 2011-07-12 12:29:49

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,240
Website

Re: THttpServerGeneric - threading, related to TSQLRestServer

You are right, TSQLRestServer.URI() is intended to be thread-safe e.g. by TSQLite3HttpServer.Request.

In fact, there was some part of it which was not perfectly thread-safe yet.

I've made some modifications, according to the following guidelines:
- most of the content is to process the incoming parameters, so is thread-safe by design (e.g. Model and RecordProps access do not change during process)
- SQLite3 engine access is protected at SQL/JSON cache level, via DB.LockJSON() calls in TSQLRestServerDB methods
- TSQLRestServerStatic main methods (EngineList, EngineRetrieve, EngineAdd, EngineUpdate, EngineDelete, EngineRetrieveBlob, EngineUpdateBlob) are thread safe: e.g. TSQLRestServerStaticInMemory uses a per-Table Critical Section
- TSQLRestServerCallBack methods (i.e. published methods of the inherited TSQLRestServer class) must be implemented to be thread-safe
- fSessionCriticalSection is used to protect shared fSession[]
- access to fStats was not made thread-safe, since this data is indicative only

See http://synopse.info/fossil/info/dce5d3a664


We tried to make the internal Critical Sections as short as possible, or relative to a table only (e.g. for TSQLRestServerStaticInMemory).

There is some kind of "giant lock" at the SQLite3 engine level, so all requests process will be queued. This was not found to be a major issue, since the internal SQL/JSON cache implementation need such a global lock, and since most of the SQLite3 resource use will consist in hard disk access, which gain to be queued.


So, to answer directly your question, the TSQLRestServerCallBack methods are expected to be thread-safe.

I've updated the documentation to explicitly states this requirement:

An important point is to remember that the implementation of the callback method must be thread-safe. In fact, the TSQLRestServer. URI method expects such callbacks to handle the thread-safety on their side. It's perhaps some more work to handle a critical section in the implementation, but, in practice, it's the best way to achieve performance and scalability: the resource locking can be made at the tiniest code level.

Offline

#3 2011-07-12 15:34:16

migajek
Member
Registered: 2010-10-01
Posts: 89

Re: THttpServerGeneric - threading, related to TSQLRestServer

ab wrote:

I've updated the documentation to explicitly states this requirement:

An important point is to remember that the implementation of the callback method must be thread-safe. In fact, the TSQLRestServer. URI method expects such callbacks to handle the thread-safety on their side. It's perhaps some more work to handle a critical section in the implementation, but, in practice, it's the best way to achieve performance and scalability: the resource locking can be made at the tiniest code level.

thank you smile

Is there some possibility to have my Service notified when new thread is shipped?

Offline

#4 2011-07-12 18:08:37

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,240
Website

Re: THttpServerGeneric - threading, related to TSQLRestServer

migajek wrote:

Is there some possibility to have my Service notified when new thread is shipped?

What do you mean exactly?

All server threads are created at once, at HTTP server initialization.
One thread pool is allocated, and will be used during work.
There is no other thread created during the server run.

You can use GetThreadID to retrieve the current Thread ID which runs the request.

To make your routine thread-safe, the easiest is to use a TRTLCriticalSection.

Offline

#5 2011-07-13 09:38:14

migajek
Member
Registered: 2010-10-01
Posts: 89

Re: THttpServerGeneric - threading, related to TSQLRestServer

ab wrote:

All server threads are created at once, at HTTP server initialization.

I thought threads creation depends on number of requests (like FastCGI) wink

Offline

#6 2011-07-13 12:53:39

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,240
Website

Re: THttpServerGeneric - threading, related to TSQLRestServer

migajek wrote:
ab wrote:

All server threads are created at once, at HTTP server initialization.

I thought threads creation depends on number of requests (like FastCGI) wink

Not in this case, since we use a thread pool, i.e. a fixed list of thread, used when necessary.
For FastCGI, it is the same: you have to specify how many process you want to fork in the config file.

Offline

#7 2011-07-13 13:05:12

migajek
Member
Registered: 2010-10-01
Posts: 89

Re: THttpServerGeneric - threading, related to TSQLRestServer

well I'm not sure how about FastCGI specs, but on my linux-running http server, FastCGI is configured with MAX number of threads to spawn. However when server starts it spawns several threads, and - as request number raises - it spawns new threads, until number reaches max.

Offline

Board footer

Powered by FluxBB