You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King, III (JIRA)" <ji...@apache.org> on 2016/06/02 16:16:59 UTC

[jira] [Created] (THRIFT-3848) As an implementer of a perl socket server, I do not want to have to remember to ignore SIGCHLD for it to work properly

James E. King, III created THRIFT-3848:
------------------------------------------

             Summary: As an implementer of a perl socket server, I do not want to have to remember to ignore SIGCHLD for it to work properly
                 Key: THRIFT-3848
                 URL: https://issues.apache.org/jira/browse/THRIFT-3848
             Project: Thrift
          Issue Type: Bug
          Components: Perl - Library
    Affects Versions: 0.9.3, 0.9.2, 0.9.1, 0.9, 0.8
         Environment: Ubuntu 14.04, perl forking server, C++ client
            Reporter: James E. King, III
            Assignee: James E. King, III


In a project I work on, we use a perl thrift server as a mock to simulate something in production.  A C++ client connects, makes a call, and disconnects.  The perl server is a forking server.

I found that if I do not explicity ignore SIGCHLD, I can accept one connection and process it, but when it disconnects, the subsequent accept call is interrupted by a SIGCHLD and results in a useless handle that can_read says cannot be read.  This puts Server.pm into an infinite accept/read/fail loop.

Question to those in the know... should perl's ForkingServer serve() implementation explicitly set SIGCHLD to IGNORE to avoid this situation?  If we do not, folks trying to use it might be as confounded as I was as to why this is happening.  If we do, it might change the behavior of programs using the perl forking server.

My inclination is to document this behavior, that perl's ForkingServer will set SIGCHLD to IGNORE for proper operation.

Tagging [~djnym], [~jensg], [~nsuke] for comment.  I've observed this behavior as far back as thrift-0.8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)