generate_hsieh_consistent Testing generate_data 6.983 [ ok ] Testing get_read 5.545 [ ok ] Testing delete_generate 5.143 [ ok ] Testing generate_data 7.173 [ ok ] Testing mget_read 1.369 [ ok ] Testing mget_read_result 1.379 [ ok ] Testing mget_read_function 1.308 [ ok ] Testing mdelete_generate 1.001 [ ok ] Testing cleanup 0.047 [ ok ]
I've added this function:
memcached_return memcached_fetch_execute(memcached_st *ptr,
unsigned int (*callback[])(memcached_st *ptr, memcached_result_st *result, void *context),
void *context,
unsigned int number_of_callbacks
);
Instead of fetching a result, you can specify a callback function to run on each result. It is up to you as to what you do. Sean Chittenden at the hackathon suggested the function array interface. Typically I just have a single callback, but he had a couple of cases where it was more useful to handle it this way. In the callback you can create threads... do whatever you like really. The context param just allows you to keep state. This method of handling results is benchmarking slightly better then the "fetch and use while()".
As an example of how to use it:
unsigned int callback_counter(memcached_st *ptr, memcached_result_st *result, void *context)
{
unsigned int *counter= (unsigned int *)context;
*counter= *counter + 1;
return 0;
}
By passing a pointer to the memcahced_st you are given the option of cloning the memcached_st, and then executing whatever commands you want against the memcached cluster.
Hopefully Patrick will read this and come up with an idea on how to use this from within UDF to extend the callback references in side of MySQL. Without Antony's current work on functions, I can't think of a way to make this reissue SQL commands in the DB (ok... I can... but it would be ugggllly...).