C Examples
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 

Description : 

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  

See Also : MXAddApplicationProcedure, MXRemoveApplicationProcedure 

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.


  • 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.
  • more complex - you may need to build state machines.
  • requires a fundamentally different approach to programming that can be confusing at first.