Author cagney
Recipients cagney, ebizzinfotech, gregory.p.smith, hugh, lukasz.langa, ned.deily, vstinner
Date 2019-04-08.15:32:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554737543.4.0.925186419622.issue36533@roundup.psfhosted.org>
In-reply-to
Content
I think the only pragmatic solution here is to add an optional parameter to logging.basicConfig() that specifies that the logger should use a single global lock; and then start documenting that thread locks and fork() don't work well together.

And note that this solution is pragmatic, not correct (@dhr, when we discussed this off line, pointed out that since python's using threads then a "correct" solution would be to use some sort of inter-process lock).

For instance, if I were to implement emit() as something contrived like:

    with lock:
        s = record.to-string()
        for i in 1 .. s'length:
            b[i] = s[i]
        for i in 1 .. b'length:
            stdout.write(b[i]).flush()
        b = []

then when fork() breaks 'lock' the guarantee that the code is atomic is also broken:

- when the child enters the code 'b' is undefined
- the guarantee that log records don't interleave is lost

while a global lock would help mitigate the first case it really isn't a "correct" fix.
History
Date User Action Args
2019-04-08 15:32:23cagneysetrecipients: + cagney, gregory.p.smith, vstinner, ned.deily, lukasz.langa, hugh, ebizzinfotech
2019-04-08 15:32:23cagneysetmessageid: <1554737543.4.0.925186419622.issue36533@roundup.psfhosted.org>
2019-04-08 15:32:23cagneylinkissue36533 messages
2019-04-08 15:32:23cagneycreate