mail::account::process — Process pending events


#include <libmail/mail.H>

class myCallback : public mail::callback {
    void success(std::string msg);
    void fail(std::string msg);

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

mail::account::function( parameter list,
                         myCallback &callback)

for (;;)
  std::vector<mail::pollfd> pollfds;
  int timeout;

  timeout=15 * 60 * 60 * 1000;

mail::account::process( pollfds,

  if (myCallback.completed())

  if (mail::account::poll(pollfds, timeout) < 0 && errno != EINTR)


This function processes all pending events for all opened mail accounts. Most mail requests are not immediately processed (some are, but most aren't). A mail request usually includes a mail::callback-derived object as one of its arguments. When the mail request completes the success or fail method (some mail::callback subclasses use additional or alternative methods) is invoked. If the mail request cannot be completed immediately, mail::account::function still returns right away. mail::account::process handles any pending events for all outstanding mail requests. The success or fail method will be invoked for all completed requests.

The mail::pollfd structure is a C++ wrapper for the struct pollfd that's used by the poll(2) system call. mail::account::process receives a reference to a vector of mail::pollfd objects. After mail::account::process handles any pending events, the function initializes the vector with all open file descriptors on which activity is expected before mail::account::process expects any more events to occur.

Any existing contents of the mail::pollfd vector will be destroyed. On the other hand, timeout must be initialized prior to invoking mail::account::process. timeout contains a time interval, in milliseconds, before the calling application expects to process any regularly-scheduled event. If mail::account::process expects any regularly-scheduled event to occur earlier, it will replace timeout with the smaller timeout interval.

The expectation is that the application's main loops alternatively invokes mail::account::process and poll(2). poll(2) waits for some I/O occur, or a timeout expiring; mail::account::process processes any resulting events, then the cycle repeats.

The application may add its own file descriptors to the mail::pollfd vector, before calling poll(2). The application is reponsible for handling any I/O activity from its own file descriptors.

Return Codes

mail::account::process always returns succesfully.


The application should not invoke mail::account::process again until it either invokes poll(2) (directly or via mail::account::poll(3x)), or until the application calls another LibMAIL function.