-1

Having a blocking subscription running like below halts the program at redisGetReply (source: hiredis#pipelining)

void subscribe (std::string& key, Subscriber* subscriber)
{
    void* reply = redisCommand (redis, "SUBSCRIBE %s", key.c_str ());
    freeReplyObject (reply);
    while (redisGetReply (redis, &reply) == REDIS_OK)
    {
        subscriber -> notify ();
        freeReplyObject (reply);
    }
}

I thought by invoking redisFree (thru signal handling) the socket would be closed and redisGetReply returned, as mentioned at hiredis#cleaning-up, instead it throws a memory access violation.

Ben
  • 807
  • 1
  • 8
  • 22
  • I am not sure why this question is voted down so much. I have the same question since I don't want to re-implement all my redis code to use the async API when a simple disconnect request might be possible with blocking operations too. – zzz Jan 24 '23 at 00:39

1 Answers1

0

Okay, nevermind. I managed to simply close the file descriptor which is being used by hiredis by invoking...

close (redis -> fd);

... and redisGetReply returns properly.

Alternatively, one could send a QUIT command and the blocking subscription returns.

Ben
  • 807
  • 1
  • 8
  • 22
  • AFAIK hiredis blocking API is not thread safe and you are not supposed to send commands like QUIT from another thread (or signal handler). Closing the socket/file descriptor would work, but uses internal OS dependant implementation details. For OS independent approach redisReconnect() does disconnect too, but that might not be thread safe - a bit like sending QUIT. It would be nice to have proper disconnect() that is documented and implemented in thread safe manner (OSes support it anyway, shouldn't be too hard). – zzz Jan 24 '23 at 01:12