On Wed, 29 Nov 2006, Stanley Yue wrote:
After reading some of the documentations on the client library, I'm still
not quite sure about the threading model of the library:
c-client was written prior to most of the current threading libraries in
common use today. Threading applications have been written using
c-client, but these were manually threaded instead of using a threading
library.
Most current threading libraries do not maintain much of a per-thread
state. For example, strtok() (which is used a fair amount by c-client) is
not thread-safe in most threading libraries since the strtok() state is
kept in a global rather than in per-thread state.
Another thing that tends to confuse novices is that c-client itself has a
good many globals. These globals are *intended* to be global across all
threads; e.g., configuration of c-client's environment.
If all this sounds complicated to you, it probably is. If you're not
familiar how people threaded applications prior to threading libraries,
you will probably be frustrated by c-client.
From the documentations, here are the steps invovled for searching for
messages in the mailbox.
Step 1: call mail_search or mail_search_full passing in the search criteria.
Step 2: the mm_search callback will be invoked for each message that match
the criteria.
1) Can we assume that Step 2 and Step 1 will always be executed by the same
thread?
Yes.
If you think about object-oriented programming, the callbacks are methods
and the MAILSTREAM is the object. Some methods are provided by c-client
and some by your application.
And that the callback will be invoked before returning from the
mail_searchXX calls?
Yes. However, usually applications don't do anything with the
mm_searched() callback. Instead, they leave that callback as an empty
function, and then scan the mail_elt(stream,msgno)->searched flags.
Similarly for other callbacks they just note the event and do the actual
task when the function returns.
Also, what if mulitple callbacks are invoked? Will they
be invoked sequentially using the same thread? Can we assume the same for
other mail_XXX api calls?
In general, yes. But usually this isn't an issue.
2) Will any of the mm callbacks ever be invoked asynchronously by threads
created by imap client library?
Although callsbacks are synchronous from function calls, you can get any
callback at any time. For example, a mail_subscribe() function call might
end up having an mm_exists() or mm_flags() callback. That is why the
MAILSTREAM is in the callback; the MAILSTREAM tells you of the event.
Or will the callbacks be only executed in
respond to some mailbox operations (i.e. mail_ping), and using the same
thread as that thread used to invoke the operation?
Any operation can trigger (almost) any callback. There are obvious
exceptions; generally you won't get mm_searched() unless a mail_search()
is in progress. But you shouldn't make any assumptions on that point.
I'm mostly thinking
about the situation where the same mailbox is open by multiple processes.
Will operations by one process trigger asynchronous callbacks to the second
process?
Yes, they can: exists, flags, expunged are all possible.
3) I'm trying to develop a synchronous wrapper library on top of the uw imap
library. However, due to the asynchronous nature of the uw library (i.e.
responses are typically delivered through the mm callback methods), I find
myself having to do a lot of caching myself. I.e. My mm_search callback
method have to cache the matched messages, so that when the mail_search api
returns, I can then return the match messages through my wrapper interface.
Am I in the right track?
I'd use the searched flags and not the callback.
You can only have one c-client operation in progress on a MAILSTREAM at a
time, otherwise the mail_lock() mechanism will punish you. [This means,
in general, that you generally can not call a mail_???() function from a
callback]. What's good about this is that you can rely upon that property
by associating the MAILSTREAM with whatever execution thread you have.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
