------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1007
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #5 from Phil Pennock <pdp@???> 2010-07-11 22:57:23 ---
log_buffer: agreed, I was just looking at that and had decided we needed a
separate log_buffer, before I saw your comments here.
The fundamental problem here is that exiwhat is asking running,
single-threaded, programs to interrupt what they're doing, say what they're
doing, then continue where they were before, without undue delay. Without
going multi-threaded, which many of the platforms which Exim supports do not
support, our options are limited; we could get rid of the functionality
entirely, to be completely "clean", but it's useful functionality for the
administrators.
Yesterday, I did look through the system implementation of the calls on my OS,
but I'm not running the same OS as the reporter. On my OS, the only locking is
if the program is built to be run threaded, which Exim is not. Since Exim does
not run threaded, the deadlock doesn't occur and it's a matter of whether or
not data is overwritten.
Rather than "how could you be so stupid to have written things that way",
constructive suggestions would help.
While thread-safety is not sufficient to be async-signal-safe, it does remove
the opportunity to overwrite data in common storage which leads to data
corruption. Between using the *_r() functions and using a separate log_buffer
for LOG_PROCESS, we're rid of the corruption and down to deadlock.
The original reporter hasn't replied to my question about whether setting
timezone = UTC alleviates the problem.
I believe that *_r() calls, a separate log_buffer, perhaps short-circuiting
some more of log_write() if LOG_PROCESS is set, and coercing the timezone to
UTC for LOG_PROCESS (to use gmtime_r() instead of localtime_r() and not have to
worry about $TZ) would reduce the window for problems.
Not "safe", but "safer".
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
