No, I don't mean recursive. I mean the callback might need to read (or write) some state that's different than the state used by other, concurrent instances of

No, I don't mean recursive. I mean the callback might need to read (or write) some state that's different than the state used by other, concurrent instances of the callback, or other arbitrary threads, so the framework should provide a means for it to get at that state that doesn't rely on say, global variables, so that multiple instances of the callback may be running concurrently with different state. Typically this is done with a cookie (in C, a "void *" parameter is generally used for this.) Basically, if you write a framework that has callbacks, and you don't make allowance for passing such a context cookie, you're imposing a constraint on your users that you might not mean to. Maybe "re-entrant" wasn't quite the right word, but in my defense, the qsort_r() man page contains this: "In this way, the comparison function does not need to use global variables to pass through arbitrary arguments, and is therefore reentrant and safe to use in threads." In addition to allowing one to write re-entrant callbacks, it also allows passing in arbitrary data of whatever kind, not just whatever parameters the framework author happened to think of.