Developers of Sympa

[András Bendzsák <address@concealed>]

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


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

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

-- 
Andras Bendzsak