Description
-
Determines if users are running in separate threads.
Property type
-
A ThreadTypes
enumeration.
Syntax
-
object.Threads [= value]
The Threads Property syntax has these parts:
object |
An expression evaluating to an object
of type wodImapServer. |
value |
A ThreadTypes
enumeration, as described in settings. |
Settings
-
The settings for value are:
|
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 wodImapServer will create new
thread for each connected user, 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
wodImapServer 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
freed so they can fire their events (such as ListMessages,
ReadMessage
etc..). As long as you don't put some lengthy processing
code inside event body - it will work nicely. 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.
|