[Python-checkins] python/dist/src/Modules posixmodule.c,2.296,2.297

[aimacintyre@users.sourceforge.net]

Update of /cvsroot/python/python/dist/src/Modules
In directory sc8-pr-cvs1:/tmp/cvs-serv22099

Modified Files:
	posixmodule.c 
Log Message:
apply Mark Hammond's PEP 311 changes to the EMX ripoff of the Windows 
popen[234]() code


Index: posixmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.296
retrieving revision 2.297
diff -C2 -d -r2.296 -r2.297
*** posixmodule.c	21 Apr 2003 14:19:51 -0000	2.296
--- posixmodule.c	21 Apr 2003 14:22:36 -0000	2.297
***************
*** 3557,3578 ****
   * files to be closed in any order - it is always the close() of the
   * final handle that will return the exit code.
   */
  
-  /* RED_FLAG 31-Aug-2000 Tim
-   * This is always called (today!) between a pair of
-   * Py_BEGIN_ALLOW_THREADS/ Py_END_ALLOW_THREADS
-   * macros.  So the thread running this has no valid thread state, as
-   * far as Python is concerned.  However, this calls some Python API
-   * functions that cannot be called safely without a valid thread
-   * state, in particular PyDict_GetItem.
-   * As a temporary hack (although it may last for years ...), we
-   * *rely* on not having a valid thread state in this function, in
-   * order to create our own "from scratch".
-   * This will deadlock if _PyPclose is ever called by a thread
-   * holding the global lock.
-   * (The OS/2 EMX thread support appears to cover the case where the
-   *  lock is already held - AIM Apr01)
-   */
- 
  static int _PyPclose(FILE *file)
  {
--- 3557,3565 ----
   * files to be closed in any order - it is always the close() of the
   * final handle that will return the exit code.
+  *
+  * NOTE: This function is currently called with the GIL released.
+  * hence we use the GILState API to manage our state.
   */
  
  static int _PyPclose(FILE *file)
  {
***************
*** 3583,3588 ****
  	int file_count;
  #ifdef WITH_THREAD
! 	PyInterpreterState* pInterpreterState;
! 	PyThreadState* pThreadState;
  #endif
  
--- 3570,3574 ----
  	int file_count;
  #ifdef WITH_THREAD
! 	PyGILState_STATE state;
  #endif
  
***************
*** 3593,3620 ****
  
  #ifdef WITH_THREAD
! 	/* Bootstrap a valid thread state into existence. */
! 	pInterpreterState = PyInterpreterState_New();
! 	if (!pInterpreterState) {
! 		/* Well, we're hosed now!  We don't have a thread
! 		 * state, so can't call a nice error routine, or raise
! 		 * an exception.  Just die.
! 		 */
! 		 Py_FatalError("unable to allocate interpreter state "
! 		 	       "when closing popen object.");
! 		 return -1;  /* unreachable */
! 	}
! 	pThreadState = PyThreadState_New(pInterpreterState);
! 	if (!pThreadState) {
! 		 Py_FatalError("unable to allocate thread state "
! 		 	       "when closing popen object.");
! 		 return -1;  /* unreachable */
! 	}
! 	/* Grab the global lock.  Note that this will deadlock if the
! 	 * current thread already has the lock! (see RED_FLAG comments
! 	 * before this function)
! 	 */
! 	PyEval_RestoreThread(pThreadState);
  #endif
- 
  	if (_PyPopenProcs)
  	{
--- 3579,3584 ----
  
  #ifdef WITH_THREAD
! 	state = PyGILState_Ensure();
  #endif
  	if (_PyPopenProcs)
  	{
***************
*** 3679,3693 ****
  
  #ifdef WITH_THREAD
! 	/* Tear down the thread & interpreter states.
! 	 * Note that interpreter state clear & delete functions automatically
! 	 * call the thread clear & delete functions, and indeed insist on
! 	 * doing that themselves.  The lock must be held during the clear, but
! 	 * need not be held during the delete.
! 	 */
! 	PyInterpreterState_Clear(pInterpreterState);
! 	PyEval_ReleaseThread(pThreadState);
! 	PyInterpreterState_Delete(pInterpreterState);
  #endif
- 
  	return result;
  }
--- 3643,3648 ----
  
  #ifdef WITH_THREAD
! 	PyGILState_Release(state);
  #endif
  	return result;
  }