🚀 go-pugleaf

"Vladimir Stefanovic" <antivari@po.sbb.co.yu> wrote in message
news:4337dfe1$1@newsgroups.borland.com...

> Is try/catch needed at all in case of spawning the thread in a service
> (to prevent the service from shuting down because of unhandled exception)?

The service will not be shut down.  However, the TServerSocket will not
function properly anymore.  On order to use the OnGetThread event in the
first place, the TServerSocket has to be set to ServerType=stThreadBlocking.
As such, the TServerSocket uses a worker thread to listen for and accept
incoming client connections.  The OnGetThread event is triggered in the
context of that worker thread.  If the OnGetThread event handler throws an
uncaught exception, the listening thread will be aborted prematurely.

On the other hand, if the OnGetThread event handler does not return a valid
thread object, TServerSocket will simply create its own thread object
internally.  Which means that not only will the thread not invoke your
processing code at all, but also if the original exception was related to
memory problems then the TServerSocket creating its own thread object could
potentially run into the same problem and throw another exception anyway.

> Should I place Enter/Leave/CriticalSection here or in
> the body of AddRequestToSharedStringList()

A critical section should be locked for as short a time as possible,
wrapping only the code that actually needs protecting.  It is best to place
it inside of AddRequestToSharedStringList() in the place(s) where the
TStringList is actually being accessed.

> Can I trust to '__finally' or it's better to use RAII?

In the code sample you have shown, it does not matter because your use of a
__finally is useless.  You placed it outside of the exception handler, in a
place where code is already guaranteed to run regardess of whether an
exception occurs, so the __finally is redundant.  For a __finally to be
effectively, it should be used before the exception is caught, ie:

    void __fastcall TEmailServerThread::AddRequestToSharedStringList( /*
ARGS */ )
    {
        try
        {
            EnterCriticalSection( &EmlSrvCriticalSection );
            try
            {
                MyStringList->Add ( /* ARGS */ );
            }
            __finally
            {
                LeaveCriticalSection( &EmlSrvCriticalSection );
            }
        }
        catch ( const Exception &e )
        {
            // ...
        }
    }

On the other hand, there is nothing wrong with using RAII, if you do not
want to use Borland-specific compiler extensions:

    struct CritSecLock
    {
        LPCRITICALSECTION fcs;
        CritSecLock(LPCRITICALSECTION acs) : fcs(acs) {
EnterCriticalSection(fcs) };
        ~CritSecLock() { LeaveCriticalSection(fcs) };
    };

    void __fastcall TEmailServerThread::AddRequestToSharedStringList( /*
ARGS */ )
    {
        try
        {
            CritSecLock lock(&EmlSrvCriticalSection);
            MyStringList->Add ( /* ARGS */ );
        }
        catch ( const Exception &e )
        {
            // ...
        }
    }

> Where should I place the sending code?

That depends on where you need to send your data from, and also what kind of
commuication protocol you are trying to implement in the first place.

>       ServiceThread->ProcessRequests( false );

Get rid of that. Your socket threads have no business calling that at all.

> In the code above, I send all the list within a CriticalSection.
> Is it smarter to spawn the CriticalSection in the body of
> SendEmailsFromList() and spaw it for *every* single item to be sent,
> and so leave ServerSocketGetThread() to 'breathe' ?

That depends on whether you need to add new items to the list at the same
time that you are sending them, or if the sending is turning out to be too
much of a bottleneck for you.  Only you can answer that question for
yourself.


Gambit