Jim Wallace wrote:
> Thanks for the reply. Just to confirm, from reading the link, if I use
> store/store_next, I can give the StoreQueryResult to another thread
> since the first is finished consuming the results and the entire result
> set is in the StoreQueryResult. (Looking at the code, that looks safe
> since I'm just calling vector::at())
That sounds right, particularly with v3.0+, where there are fewer hidden
links between MySQL++ data structures and the low-level C data
structures returned by the MySQL C API library.
That said, beware that I'm not writing from experience, since, as you
know, I believe threads are evil. I only use them for applications so
trivial that they cannot fail.
(Not that you asked, but my company's primary product achieves
concurrency through message-passing among independent single-threaded
processes. Each process uses async I/O to keep it responsive. We don't
need no steenking threads.)
You might want to download the svn version of MySQL++ and build the user
manual. I've just finished reworking the threads chapter and the
tutorial section on concurrent queries to clarify several things.
