Developers of Sympa

[David Verdin <address@concealed>]

Le 06/01/11 22:41, András Bendzsák a écrit :
> > Each time a daemon starts and it finds a pre-existing<daemon>.pid file.
> > This is located in the tools::write_pid() function.
> > I didn't find any other occurrence of this operation. So I guess we
> > could add an argument to the Lock::_lock_file() function specifying that
> > the pid must be written and use it in tools::write_pid(). We could then
> > get rid of most of the write operations when locking a file.
> Hmm...I checked that part of the code. I don't see any connection
> tools::write_pid() and Lock::_lock_file(). The function handles the
> locking itself.
> And as I see there is a separate lock/unlock function in the tools.pm
> which is maybe not used anymore...
This function is still used. This is the top level function to 
lock/unlock files. It calls _lock_file that do the actual work, with 
lower level parameters.
tools::write_pid doen't use _lock_file (or lock) but it should. As at 
least one of the Sympa daemon is now multi-instantiable, we must use 
_lock_file to handle concurrency on the <dameon>.pid files.
It's a recent problematic, though.
> > The admin_table is in the database, so we don't need a filesystem lock.
> > The stats are useless for the list of lists.
> > However we read the config to know which visibility scenario will be
> > used. I should check it but if the binary config are written only when
> > the CGI loads ANd the config has changed, there should not be any
> > writing when displaying the list of lists.
> To make it clear: the issue is present only when the CGI loads.
> I traced the cgi daemon and grepped the write open system functions.
> The results:
> - include_admin_user.lock (2x)
> - config.lock
> - stats.lock
> - stats
> These files are opened for writing for every lists. You can imagine what
> happens with thousands of lists.
OK. i thought you had trouble to display the list of lists only. I'll 
also have a look at these operations and see whether the pid writing is 
really necessary. If it is never read, I think we don't need to write it...
> > Improving the list of lists display performances is on my short term
> > todo list, so I'll check why we use write locks for this operation.
> Great! Feel to free to contact me if you need any help.
Thanks. I will if I need.

Regards,

David