Question

reply = redisCommand(rcontext,"HGET %u %u",env->cr[3] ,KeyHandle);
if(reply == NULL)
{
printf("in preNtDeletKey rediscommand error ! and the err type is %d the string is %s \n" ,rcontext->err,rcontext->errstr)";
}

Here I got a error , the reply return NULL
the output is

in preNtDeletKey rediscommand error ! and the err type is 1 the string is Interrupted system call

I use this in my project . And i grep in the hiredis source don’t find Interrupted system call
I want to know what the reason to cause a Interrupted system call
How hiredis write the string to the redisContext (because I don’t find in the sourec)

How we avoid the Interrupted system call ?

Answer 1

The hiredis package marshals your command using the Redis protocol, and sends it to the Redis server. It then synchronously waits for the reply.

You will find the functions dealing with the sockets in the hiredis.c file:

int redisBufferRead(redisContext *c)
int redisBufferWrite(redisContext *c, int *done)

In these functions, the EAGAIN error is handled, but not the EINTR error which corresponds to the “Interrupted system call” message.

The consequence is any Unix signal, received by the process when hiredis is doing a write or (more likely) a read operation, can interrupt the operation and cause this error.

You need first to understand which kind of signal the application receives. Depending on the nature of the signal and the application, there are various ways to handle this situation:

• masking or deferring signal handlers before doing Redis calls
• binding the signal to an event loop handler (if any) to avoid the signal to be processed when it is not expected
• dedicate a given thread to handle all signals (and avoid any Redis calls in this thread)
• using the SA_RESTART option (in sigaction) to tell the system to replay interrupted system calls automatically
• just try to do the operation again (it might not be possible though)

Personally, I would favor hiredis to handle the situation in a more graceful way (i.e. processing EINTR just like EAGAIN).

UPDATE:

The EAGAIN error is normally returned in two situations:

• when the non blocking mode has been activated by calling redisConnectNonBlock or
  redisConnectUnixNonBlock()

• when the connection is in blocking mode (default) and the redisSetTimeout() method has been called to set a timeout

Please note calling the redisSetTimeout() functions on client side just set the SO_RCVTIMEO and SO_SNDTIMEO properties of the socket. It is completely unrelated to the timeout defined in the Redis configuration file which is a server side idle timeout (Redis server being able to close a connection if it has been inactive for more than N seconds).

Getting EAGAIN in the second situation means the Redis instance is not responsive enough for the provided timeout. You may want to simply increase the timeout or investigate further the latency issues on Redis server side.