No way to know whether to wait for readability or writability

[Wim Lewis]

When using libdrizzle in nonblocking mode, there's no way for the caller to know whether to wait for readability or writability on the socket when libdrizzle returns DRIZZLE_RETURN_IO_WAIT.

(Often it'll be waiting for readability, but it needs to wait for writability if you're sending a long query or bound parameter, or using SSL (bug #1096032), or doing nonblocking connect (bug #1211567).)

I can think of three obvious ways to extend the libdrizzle api to fix this:

- add a function drizzle_fd_waiting_for() (but with a better name) that returns POLLIN, POLLOUT, etc
- change drizzle_fd() to return both the fd and the current flags
- split DRIZZLE_RETURN_IO_WAIT into two return codes, DRIZZLE_RETURN_IO_READ and DRIZZLE_RETURN_IO_WRITE

[Marenz (marenz)]

I am pasting my answer to the related question here as well as I think it helps/is relevant:

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.

[Wim Lewis (wiml-omni)]

Copying my comment from the related question as well: if libdrizzle is waiting for data to arrive, then the socket is likely always writable. If you just wait for everything including writability, you'll never block, and will just spin in select/read burning cpu, which isn't really acceptable behavior in most cases...

[Marenz (marenz)]

Sounds like the proper way to fix this is to add back the drizzle_set_events function.