\t\t\t\tOne of the most annoying things with database calls is creating a thread to process the call.<\/p>\n
Here’s some psuedocode to illustrate the issue:<\/p>\n
void QueryDB() {
\nCreateThread(SelectResults, callback);
\n}
\nint SelectResults(Callback *callback) {
\nresult = Process(“select * from db”);
\ncallback(result);
\n}
\nvoid Callback(Result *result) {
\nprintf(“result is %i”, result);
\n}<\/p>\n
Doing the same thing inline is much easier. It’s one function rather than 3, and you also have context about the call.<\/p>\n
void QueryDB() {
\nresult = Process(“select * from db”);
\nprintf(“result is %i”, result);
\n}<\/p>\n
However, it blocks your entire program.<\/p>\n
I came up with an “InlineFunctorProcessor” system that has the benefits of both. It allows you to do blocking calls all within the context of one function, but runs the blocking call in a thread while your program continues running.<\/p>\n
printf(“Enter file to read: “);
\nReadFileFunctor *rff = new ReadFileFunctor;
\ngets(rff->fn);
\n\/\/ Nonblocking, but processes as easily as if it were
\nYieldOnFunctor(rff);
\nif (rff->data)
\n\tprintf(“Got file data\\n%s\\n”, rff->data);
\nelse
\n\tprintf(“Open failed\\n”);
\ndelete rff;<\/p>\n
The way the system works is through recursion, thus saving prior calls on the stack. The yield function calls the main application update loop – or any other function you want to call while the function is processing. That function is responsible for calling InlineFunctorProcessor::UpdateIFP(), which if it returns true, the function should also return.<\/p>\n
Here’s the code for the base class:
\nHeader<\/a>
\nSource<\/a><\/p>\n