mail::account::process — Process pending events
#include <libmail/mail.H>
class myCallback : public mail::callback {
public:
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, |
timeout) ; |
if (myCallback.completed())
break;
if (mail::account::poll(pollfds, timeout) < 0 && errno != EINTR)
{
error();
}
}
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,
still returns right away. mail::account::function
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.
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.