Richard Perini
unread,Jan 24, 2023, 8:58:26 AM1/24/23Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to redi...@googlegroups.com
Hi,
I recently upgraded our hiredis client library from 0.10.1 to 1.1.0.
Following the upgrade, our processes that use the BRPOPLPUSH verb ceased
responding to SIGINT or SIGTERM, i.e. became uninterruptible while blocked
waiting for a new element on the list. The processes in question have been
running happily for years with the old driver.
I tracked this down to a change in the handling of the error return from recv()
(net.c redisNetRead() in the case of 1.1.0), versus similar handling for read()
in the old version (hiredis.c redisBufferRead() in 0.10.1).
The old version used to respond to EINTR by setting REDIS_ERR_IO with
__redisSetError(c,REDIS_ERR_IO,NULL) and return REDIS_ERR (-1).
The new version "ignores" EINTR by returning 0 from redisNetRead(), without
setting REDIS_ERR_IO. This in turn prevents redisGetReply() from ever
breaking out of the while(aux == NULL) loop.
I changed redisNetRead() to treat EINTR as it used to, by calling
__redisSetError(c, REDIS_ERR_IO, strerror(errno)); and returning -1, which
solves the problem for me.
Have I misunderstood something, or is this a bug? If so, is my fix the
correct way to rectify it?
Thank you,
--
Richard Perini