|
|
| MXDispatchEvents |
C
NetProg Library |
|
|
#include
"mx.h"
|
|
|
LONG MXDispatchEvents (MX* pmx, DWORD milliseconds) |
|
| Parameters |
Description |
| pmx |
the
MX manager |
| milliseconds |
timeout
in milleseconds before function returning |
The MXDispatchEvents function
manages all the events related to connections (open, close), to connections
queues (input,output) and
then it dispatches the events to the appropriate registered procedures. It cooperatively schedule the cpu or other resources
to each connection
If there is nothing to process,
MXDispatchEvents blocks (No cpu is consumed) until there is
This constitutes the main loop
of the MX manager, and, as such, it does not return unless the parameter milliseconds
is different from 0
If milliseconds is 0, applications are expected to exit in response to
an event that triggers a callback procedure. If an application wants to do
some background work, it shoud use the MXAddApplicationProcedure function
If milliseconds is different from 0, this function returns every milliseconds. In
this case this function is usually called in a loop
This function is used for
asynchronous programming
Return
Values : -1 if error else returns 0
|
|
Remarks
:
With async, or 'event-driven'
programming, you cooperatively schedule the cpu or other resources you wish to
apply to each connection. How you do this really depends on the application -
and it's not always possible or reasonable to try. But if you can capture the
state of any one connection, and divide the work it will do into relatively
small pieces, then this solution might work for you. If your connections do not
require much (or any) state, then this is an ideal approach.
pros:
- efficient and elegant
- scales well - hundreds of
connections means only hundreds of socket/state objects, not hundreds of
threads or processes.
- requires no interlocking for
access to shared resources. If your database provides no interlocking of its
own (as is the case for dbm, dbz, and berkeley db), than the need to
serialize access to the database is provided trivially.
- integrates easily with
event-driven window-system programming. GUI programs that use blocking
network calls are not very graceful.
cons:
- more complex - you may need
to build state machines.
- requires a fundamentally
different approach to programming that can be confusing at first.
|
|
|
