Changes between Version 76 and Version 77 of processus_thread

Timestamp:

Feb 12, 2018, 2:53:23 PM (7 years ago)

Author:

alain

Comment:

--

processus_thread

@@ -151 +151 @@
 == __6) Process destruction__ ==
 
-The destruction of process P can be caused by a sys_exit() system call executed by any thread of process P,  or by another process executing the sys_kill() system call. It can also be caused by a CtrlC signal typed on the process terminal. In all cases, the work must be done by a thread running in the owner cluster, because all process copies must be involved, and the list of copies is rooted in the owner cluster. It must also be done by a RPC thread, because a thread cannot delete itself.
+The destruction of process P can be caused by a sys_exit() system call executed by any thread of process P,  or by another process executing the sys_kill() system call. It can also be caused by a CtrlC signal typed on the process terminal. In all cases, the work must be done by a thread running in the owner cluster, because all process copies must be involved, and the list of copies is rooted in the owner cluster. It must be done by a RPC thread, because a thread cannot delete itself.
 
-=== 6.1 parent / child synchronization
+=== 6.1 parent / children synchronization
 
-The process descriptors copies (I.e. other than the reference process descriptor) are simply deleted by the scheduler when the last thread of a given process in a given cluster is  deleted. It is removed from the list of copies in reference process cluster descriptor, and that's it. 
+The process descriptors copies (I.e. other than the reference process descriptor) are simply deleted by the scheduler when the last thread of a given process in a given cluster is  deleted. The process descriptor copy is removed from the list of copies in the owner process cluster descriptor, and that's it. 
 
-But the reference process destruction is more complex, because the child process destruction must be reported to the parent process when the parent process executes the blocking sys_wait() system call. Therefore, the child process destruction cannot be done before the parent calls the sys_wait() function. As the '''sys_wait()''' function, and the '''sys_kill() / sys_exit()''' function are executed by different threads running in different clusters, this requires a parent/child synchronization.
+But the process destruction in the owner cluster is more complex, because the child process destruction must be reported to the parent process when the parent process executes the blocking sys_wait() system call. Therefore, the child process destruction cannot be done before the parent calls the sys_wait() function. As the '''sys_wait()''' function, and the '''sys_kill() / sys_exit()''' function are executed by different threads running in different clusters, this requires a parent/child synchronization.
  
-After a sys-kill() or sys_exit(), all child process threads and all process copies are immediately destroyed, but the reference child process must be kept in ''zombi'' state if the sys_wait() syscall has not been executed.  The synchronization uses the '''term_state'''  field in the reference child process descriptor : 
+After a sys-kill() or sys_exit(), all process threads and all process copies are immediately destroyed, but the process descriptor in owner cluster is kept in ''zombi'' state :  the main thread (i.e. thread 0 in process owner cluster) is not deleted until the sys_wait() syscall is executed by the parent process.  The synchronization uses the '''term_state'''  field in the child process descriptor, that contains the following informations : 
  * the PROCESS_FLAG_KILL flag indicates that a KILL request has been received by the child;  
  * the PROCESS_FLAG_EXIT flag indicates that an EXIT  request has been made by the child;  
  * the PROCESS_FLAG_BLOCK flag indicates that a SIGSTOP signal has been received by the child; 
- * the PROCESS_FLAG_WAIT flag indicates that a WAIT  request from parent has been received by the chid and reported to parent.
- * moreover the sys_exit() argument  is registered in the ''term_state'' field of the process descriptor.
+ * the PROCESS_FLAG_WAIT flag indicates that a WAIT  request from parent has been received by the child and reported to parent.
+ * moreover the exit() argument  is registered in the ''term_state'' field of the process descriptor.
 
-The actual deletion of the reference process is always caused by the sys_wait() function, using generally a RPC:
- * If the sys_wait() arrives first, the corresponding flag is atomically set in the child reference process, and the parent main thread executing the sys_wait() is blocked. This parent thread will be unblocked when a ''kill'' or ''exit'' is received by the child, and delete the child reference process.
- * If the sys_kill() or sys_exit() arrive first, the corresponding flag is atomically set in the child reference process. When these flags are detected by the parent main thread executing the sys_wait(), it deletes the reference process descriptor.
+The actual deletion of the process descriptor in owner cluster is done by the sys_wait() function that must be executed by the parent main thread (i.e. thread 0 in parent owner cluster). This sys_wait() function executes an infinite loop. At each iteration the parent scan all children owner descriptors. When it detects that one child terminated,
+it set the PROCESS_FLAG_WAIT in child descriptor, set the THREAD_FLAG_DELETE in the child main thread, and exit to report the child termination state to parent process. It is the responsibility of the parent process to re-enter the sys_wait() sys call for the other children. When the parent does not detect a terminated child at the end of an iteration, it deschedule without blocking.  
+
 
 === 6.2) detailed destruction scenario ===
 
- 1. Both the sys_kill() or sys_exit() sys calls, use the rpc_process_make_kill_client(), to ask an RPC thread to execute the process_make_kill() function in the owner cluster (because a thread cannot kill itself).
+ 1. Both the sys_kill() or sys_exit() sys calls, use the rpc_process_make_kill_client(), to ask an RPC thread to execute the process_make_kill() function in the owner cluster (because a thread cannot delete itself).
  1. The  process_make_kill() function in owner cluster send a multicast and parallel RPC to all clusters containing a copy of the process. In each cluster, the process_block_threads() function set the BLOCKED_GLOBAL bit for all threads of the process. It returns only when all threads are blocked and descheduled. 
- 1. When the process_make_kill() function in owner cluster has received all expected responses to the first multicast RPC, it send another multicast and parallel RPC to all clusters containing a copy of the process. In each cluster, the process_delete_threads() function releases the memory allocated to the local threads. The local process descriptor is also destroyed, if it is not the reference process descriptor.
+ 1. When the process_make_kill() function in owner cluster has received all expected responses to the first multicast RPC, it send another multicast and parallel RPC to all clusters containing a copy of the process. In each cluster, the process_delete_threads() function releases the memory allocated to all local threads but the process main thread (thread 0 in owner cluster). All process descriptors copies are destroyed, but the one in owner cluster.
  1. When the process_make_kill() function in owner cluster has received all expected responses to the second multi-cast RPC, it updates the owner cluster manager
  to remove the process from the set of owned processes.
- 1. Finally, the process_make_kill() function synchronizes with the parent process, and the parent sys_wait() function delete the reference process descriptor.
+ 1. Finally, the process_make_kill() function synchronizes with the parent process, and the parent sys_wait() function delete the process descriptor in owner cluster.