[ 
https://issues.apache.org/jira/browse/QPID-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher resolved QPID-2367.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.19
    
> Early Initialization of File Descriptors Conflicts With Daemon Best Practices
> -----------------------------------------------------------------------------
>
>                 Key: QPID-2367
>                 URL: https://issues.apache.org/jira/browse/QPID-2367
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Client
>    Affects Versions: 0.5
>         Environment: Linux (possibly all UNIX), c++, g++
>            Reporter: Jason Schlauch
>            Assignee: Andrew Stitcher
>             Fix For: 0.19
>
>
> At least one file descriptor (in qpid/sys/epoll/EpollPoller.*) in the c++ 
> client is global and declared as static.  In programs linked against the c++ 
> qpid libs g++ generates code for allocation and, more importantly, 
> initialization of these descriptors that occurs before main().  You can 
> confirm this with gdb by breakpointing both the initialization and main() 
> (the initialization break is hit first).
> On the other hand, the canonical recipe for creating a UNIX daemon calls for 
> the closing of all open file descriptors after fork()ing (where the fork() 
> certainly occurs after main()).  While not an absolute requirement, closing 
> all open file descriptors is considered a best practice.  A loop to close all 
> descriptors is also common in boilerplate daemon creation code and has 
> undoubtedly been cut-and-pasted into numerous daemons.
> The net effect is that the typical daemon will close the file descriptor 
> opened before main() in the c++ client library.  In the case of the epoll 
> code this manifests as an inability to connect to the broker.
> A fix for this would be to defer the initialization of the file descriptor 
> (perhaps via the Singleton pattern or a move of the variables into a class 
> member).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to