https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6996
--- Comment #2 from Mark Martinec <[email protected]> --- > > I'd say it is a blocker. We may not bother with Windows-locking and > > just implement a simple flock, which is cheap and works well on Unix > > using a local (non-NFS) lock file, and automatically unlocks if a process > > happens to crash while holding a lock. > > My only thought perhaps them we should make an if (windows) loop and > if ip4 and v6, then round-robin is not available option as well? Some digging shows that Perl's flock on Windows is just fine since Windows XP. It may lack the LOCK_NB (nonblocking) option, but we don't need it. Also the perlport man page says: flock Not implemented (VMS, RISC OS, VOS) i.e. it does not mention Windows. So this concern was apparently a very old information. I don't remember exactly why the 'managed' scheduling was introduced, seems to me the only reason is to provide dynamic scaling of the number of child processes. When one wants a fixed number of processes, I think the 'autonomous' is just as good, if no better (for its simplicity). Here is now my change. I tried to make no impact on the 'managed' scheduling (no --round-robin), locking is only active when there are multiple sockets *and* --round-robin (autonomous child processes) is used. Also it adds some more informative debug logging, a status check in SpamdForkScaling.pm, and cosmetics (Mail::SpamAssassin::Util::untaint_file_path -> untaint_file_path) trunk: Bug 6996 - spamd --round-robin conflicts with multiple listen sockets Sending lib/Mail/SpamAssassin/SpamdForkScaling.pm Sending spamd/spamd.raw Committed revision 1563172. -- You are receiving this mail because: You are the assignee for the bug.
