<div dir="ltr">Hi all,<div><br></div><div>This week I fixed some locking bugs on the client side. In functions like shmget and shmat that are not often called and there are not so many operations to be done I have decreased the number of locks acquired. I focused on multithreading case and sysv semaphores, added locking where was the case and handled some error conditions (a semaphore was removed by another process, a semaphore was removed by another thread from the same space address, etc).</div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">During the test period, I realized that I need to handle the case when a process that uses userland sysv ipc calls fork() or exec().</span><span style="font-family:arial,sans-serif;font-size:13px"> </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">The fork() case is treated using pthread_atfork function. The parent acquires all locks before forking itself and both child and parent release them after fork. The child must than connect to the daemon and inform it about the shared memory segments </span><font face="arial, sans-serif">to which it is attached (those segments can be used for shm, sem, msg).</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">For exec() case, all file descriptors used to communicate with the daemon have </font><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px">FD_CLOEXEC set. The daemon handles this case as if the client was disconnected. There is a problem with the segment used for undo operations. All operations that have SEM_UNDO flag set (flag used by semop()) are written in this segment in order to be undone by the server when the process dies. The daemon can not make difference between exec() and the end of execution so it will undo all operations in exec() case too (the operations should be undone after the process dies).</span></div>
<div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px"><br></span></div><div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px">From the credentials point of view, I have replaced the connection to the daemon and the communication with it with sockets. I have used UNIX sockets to install a file descriptor in the client filetable and to obtain client credentials.</span></div>
<div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px"><br></span></div><div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px">For next week, more tests will be done. I will also focus on resource limits and adding multithreading capabilities to the daemon (I am thinking to use a pool of threads to handle messages received from clients).</span></div>
<div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px"><br></span></div><div><span style="color:rgb(68,68,68);font-family:arial,sans-serif;line-height:16px">Larisa</span></div></div>