[CalendarServer-changes] [11481] CalendarServer/branches/users/glyph/hang-fix/calendarserver/tap/ caldav.py
source_changes at macosforge.org
source_changes at macosforge.org
Fri Jul 5 17:43:19 PDT 2013
Revision: 11481
http://trac.calendarserver.org//changeset/11481
Author: glyph at apple.com
Date: 2013-07-05 17:43:19 -0700 (Fri, 05 Jul 2013)
Log Message:
-----------
Document the slight contradiction about how metaFD is used.
Modified Paths:
--------------
CalendarServer/branches/users/glyph/hang-fix/calendarserver/tap/caldav.py
Modified: CalendarServer/branches/users/glyph/hang-fix/calendarserver/tap/caldav.py
===================================================================
--- CalendarServer/branches/users/glyph/hang-fix/calendarserver/tap/caldav.py 2013-07-06 00:43:17 UTC (rev 11480)
+++ CalendarServer/branches/users/glyph/hang-fix/calendarserver/tap/caldav.py 2013-07-06 00:43:19 UTC (rev 11481)
@@ -1758,6 +1758,22 @@
def getFileDescriptors(self):
"""
+ Get the file descriptors that will be passed to the subprocess, as a
+ mapping that will be used with L{IReactorProcess.spawnProcess}.
+
+ If this server is configured to use a meta FD, pass the client end of
+ the meta FD. If this server is configured to use an AMP database
+ connection pool, pass a pre-connected AMP socket.
+
+ Note that, contrary to the documentation for
+ L{twext.internet.sendfdport.InheritedSocketDispatcher.addSocket}, this
+ does I{not} close the added child socket; this method
+ (C{getFileDescriptors}) is called repeatedly to start a new process
+ with the same C{LogID} if the previous one exits. Therefore we
+ consistently re-use the same file descriptor and leave it open in the
+ master, relying upon process-exit notification rather than noticing the
+ meta-FD socket was closed in the subprocess.
+
@return: a mapping of file descriptor numbers for the new (child)
process to file descriptor numbers in the current (master) process.
"""
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20130705/3f70d380/attachment.html>
More information about the calendarserver-changes
mailing list