Horton

Re: Thread-unsafe coding in ecpg

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: "Joshua D. Drake" <jd@commandprompt.com>, Andres Freund <andres@anarazel.de>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Michael Meskes <meskes@postgresql.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-24T03:10:04Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 1/23/19 6:01 PM, Tom Lane wrote:
>> Perhaps there's some sort of setup that MinGW's version needs that
>> we're not doing?

> This seems to suggest something worse: https://reviews.llvm.org/D40181
> Not sure I fully understand what's happening here, though.

Me either, but I noted a couple of interesting extracts from that page:

    Normal mingw that uses msvcrt.dll doesn't have per-thread locales so
    it won't really work in any case (but I think it does define some sort
    of dummy functions that at least will allow it to build). Nowadays,
    mingw can be built to target ucrtbase.dll as well though, and there it
    should be possible to make it work just like for MSVC although it
    might need some patches.

    ... Looked into MinGW-w64 sources and this is indeed the
    case. _configthreadlocale will return -1 and will not do anything.

This suggests that, rather than throwing up our hands if the initial
_configthreadlocale call returns -1, we should act as though the function
doesn't exist, and just soldier on the same as before.  The code in there
assumes that -1 is a can't-happen case and doesn't try to recover,
but apparently that's over-optimistic.

			regards, tom lane

Commits

  1. Remove _configthreadlocale() calls in ecpg test suite.

  2. Remove infinite-loop hazards in ecpg test suite.

  3. Blind attempt to fix _configthreadlocale() failures on MinGW.

  4. Avoid thread-safety problem in ecpglib.

  5. Second try at fixing ecpglib thread-safety problem.