How to use drizzle_query() in nonblocking mode?

Asked by Wim Lewis on 2013-07-29

I've been trying to figure out what the correct way to handle a response of DRIZZLE_RETURN_IO_WAIT from drizzle_query() is. Reading through the Drizzle source code, it's not really clear to me what the caller should do: presumably it should be using drizzle_fd+poll to wait for activity on the connection, but what does it do then? drizzle_state_loop() does what I want, but it's a private function. And how does the caller know whether it should be waiting for readability or writability on the drizzle fd?

Question information

Language:
English Edit question
Status:
Answered
For:
Drizzle Client & Protocol Library Edit question
Assignee:
No assignee Edit question
Last query:
2013-08-27
Last reply:
2015-01-21
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Wim Lewis (wiml-omni) said : #2

There doesn't seem to be a way to do this --- I'm guessing the libdrizzle api needs to be extended.

Marenz (marenz) said : #3

In the old version of libdrizzle you had to just call the query_function function again after telling drizzle about the events that happened using

/**
 * Set events that are ready for a connection. This is used with the external
 * event callbacks. See drizzle_set_event_watch_fn().
 *
 * @param[in] con Connection structure previously initialized with
 * drizzle_create(), drizzle_clone(), or related functions.
 * @param[in] revents Bitfield of poll() events that were detected.
 * @return Standard drizzle return value.
 */
DRIZZLE_API
drizzle_return_t drizzle_set_revents(drizzle_st *con, short revents);

However this references drizzle_set_event_watch_fn which was for reasons unknown to me, removed in revesion 56
The function was used by drizzle to tell an external poll mechanism what events it is interested in and when to tell it (using set_revents). Without it problems like described here arise: https://bugs.launchpad.net/libdrizzle/+bug/1220467

I think you can simply wait for everything and just call the function again. Worst case is that you'll get a IO_WAIT return value again. I think ;)

I am going to try exactly this now in any case. Can let you know how it'll go.

Marenz (marenz) said : #4

So, I am doing this now and it seems to work just fine for me.

Wim Lewis (wiml-omni) said : #5

Waiting for everything has the problem that you will spin doing nothing but consuming cpu in some common cases. For example, if libdrizzle is waiting for data from the other end, the socket is probably writable 100% of the time, and you'll never properly block because you have to keep calling in to libdrizzle. But if you got IO_WAIT because you're sending a large request, or because TLS is doing some back-and-forth under the hood, then you *do* need to respond to writability even if there's nothing to read.

Can you help with this problem?

Provide an answer of your own, or ask Wim Lewis for more information if necessary.

To post a message you must log in.