wodSmtpServer ActiveX Control - Threads Property
      
 

Description

Determines if users and relays are running in separate threads.


Property type

A ThreadTypes enumeration.  


Syntax

object.Threads [= value]



The Threads Property syntax has these parts:

Part Description
object An expression evaluating to an object of type wodSmtpServer.
value A ThreadTypes enumeration, as described in settings.

Settings

The settings for value are:

Constant Value Description
 NoThreads 0 No threads are used.
 SafeThreads 1 Threads are used, but events are fired from the main thread.
 FullThreads 2 Full thread support, events fired form worker threads.

Remarks

This property defines if wodSmtpServer will create new thread for each connected user and for each relay, or will let them all 'live' in main thread (default behavior). Having threads is important for accepting more connections at a time without freezing or slowing down your application. Since each new client runs in new thread, it will not interfere with other connected users - regardless if he is sending you new message or not.

But there is a problem - VB6 as most common environment does not encourage use of threads. Even more, it does not allow events to be fired from worker threads - only from main thread. For this purpose, Threads property can be set to SafeThreads value - in which case wodSmtpServer will always synchronize worker thread with main thread before event is fired - so your application does not crash. This may cause insignificant slowdown, since all currently connected users have to wait for main thread to be free to they can fire their events (such as HeloReceived, MailStart etc..). As long as you don't put some lengthy processing code inside event body - it will work correctly. If your code execution inside event body is lengthy - this may slow down all connected clients since they are ALL waiting for your code to be processed. Still, the most important thing is the receipt of the message body - and your code does not affect it since no events are fired at that time.

For environments that are aware of multithreading, you are free to use FullThreads setting - in which case events are fired from these threads. If you put some lengthy processing in this code only one user will be affected - all other users will still be able to talk with the server uninterrupted.

It may be a good idea to test if your environment supports FullThreads or if you need to use SafeThreads. Best way is to run your application in Debug mode, inside your IDE, and stop execution inside the event. If it crashes while having FullThreads setting - it may be better choice to use SafeThreads instead.

If you want to change this setting on a 'per user' basis, you can change it from within *each* Connecting event (which always is fired in the main thread anyway!), since after this event value of Threads property is copied for the user.