On Sep 1, 2009, at 3:31 PM, Jay Pipes wrote:
The question probably is: Who's in the expected audience, or rather
which case is likely to be more common?
In other words: How often do you really need to perform work
between sending a query and reading its result?
I guess the answer depends on how many queries the programmer can
"queue up" (to be processed in parallel by the server).
Again, in general I prefer having the function tell me right there
and then what it will do.
If the blocking behavior of drizzle_query depends on some magic
flag, then I need to be hunting around for the call
setting the flag – which might be in a completely different file –
and need to look for later calls to drizzle_result_read.
What happens when someone changes the flag from non-blocking to
blocking behavior? Will the sequence
drizzle_query("SELECT 1", result);
drizzle_result_read(result);
still work? Or will it fail or corrupt result?
drizzle_result_read() will wait until drizzle_query() for that
result struct is ready to read. The purpose of the non-blocking
drizzle_query() behaviour/flag is for when you want to do *non-
drizzle* stuff after issuing drizzle_query(). At least, I *think*
this is the case :)
ok, let me clarify what i meant:
/* flag is set to non-blocking */ /* [1] */
drizzle_query("select sleep(10000)", result); /* [2] */
something_expensive();
drizzle_read_result(result); /* [3] */
The above is scenario A.
Let's suppose someone comes along and changes it scenario B by
changing [1] above to blocking behavior (I suppose this flag is per-
drizzle struct).
In that case, IIUC, [2] will both send the query and wait for all the
packets to return from the server before returning to its caller.
Will [3] be a no-op then? That would be ok, but it could also just
fail (this is me not knowing any internals of libdrizzle!) because
there's nothing
to read anymore – for all I know drizzle_query in blocking mode
could've deallocated internal data structures that make [3] crash.
The other way around is worse:
/* flag set to blocking */
drizzle_query("select sleep(10000)", result);
/* do something with result */
/* note: no drizzle_read_result anywhere in the code! */
now change the flag to non-blocking and your code will magically stop
working, without any indication of why that might be the case (ok,
result will be empty).
in fact, now that i think about it, why does libdrizzle need the
blocking mode at all? IIUC (aka i might be wrong) all it does is:
void drizzle_query(result, …) {
/* send query somehow */
if (blocking) {
drizzle_read_result(result);
}
}
no?
now my first argument applies again: let one function do one thing :)
blocking usage would then translate to:
drizzle_query("…", result);
drizzle_read_result(result);
while non-blocking would be:
drizzle_query("…", result);
something_expensive();
drizzle_read_result(result);
no need for storing and checking a flag at all (of course this API is
unsuitable for streamed resultsets, since drizzle_read_result implies
seeing the entire set first).
hope that illustrates my point a bit better.
cheers,
-k
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Wolf Frenkel
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
