[no subject]

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).

Larisa

--90e6ba6e850086339a04e32799ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"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 of=
ten 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 se=
maphores, added locking where was the case and handled some error condition=
s (a semaphore was removed by another process, a semaphore was removed by a=
nother thread from the same space address, etc).</div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Dur=
ing the test period, I realized that I need to handle the case when a proce=
ss that uses userland sysv ipc calls fork() or exec().</span><span style=3D=
"font-family:arial,sans-serif;font-size:13px">=A0</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px">The fork()=
 case is treated using pthread_atfork function. The parent acquires all loc=
ks 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 m=
emory segments=A0</span><font face=3D"arial, sans-serif">to which it is att=
ached (those segments can be used for shm, sem, msg).</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">For exec() case, all file descriptors used to communicate=
 with the daemon have=A0</font><span style=3D"color:rgb(68,68,68);font-fami=
ly:arial,sans-serif;line-height:16px">FD_CLOEXEC set. The daemon handles th=
is case as if the client was disconnected. There is a problem with the segm=
ent used for undo operations. All operations that have SEM_UNDO flag set (f=
lag used by semop()) are written in this segment in order to be undone by t=
he 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() c=
ase too (the operations should be undone after the process dies).</span></d=
iv>
<div><span style=3D"color:rgb(68,68,68);font-family:arial,sans-serif;line-h=
eight:16px"><br></span></div><div><span style=3D"color:rgb(68,68,68);font-f=
amily:arial,sans-serif;line-height:16px">From the credentials point of view=
, I have replaced the connection to the daemon and the communication with i=
t with sockets. I have used UNIX sockets to install a file descriptor in th=
e client filetable and to obtain client credentials.</span></div>
<div><span style=3D"color:rgb(68,68,68);font-family:arial,sans-serif;line-h=
eight:16px"><br></span></div><div><span style=3D"color:rgb(68,68,68);font-f=
amily:arial,sans-serif;line-height:16px">For next week, more tests will be =
done. I will also focus on resource limits and adding multithreading capabi=
lities to the daemon (I am thinking to use a pool of threads to handle mess=
ages received from clients).</span></div>
<div><span style=3D"color:rgb(68,68,68);font-family:arial,sans-serif;line-h=
eight:16px"><br></span></div><div><span style=3D"color:rgb(68,68,68);font-f=
amily:arial,sans-serif;line-height:16px">Larisa</span></div></div>

--90e6ba6e850086339a04e32799ef--