From: | Michael Loftis <mloftis(at)wgops(dot)com> |
---|---|
To: | "Michael J(dot) Baars" <mjbaars1977(dot)pgsql(dot)hackers(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: libpq and multi-threading |
Date: | 2023-05-03 12:35:26 |
Message-ID: | CAHDg04t0hL5Sgf6LQGnLYYCthUYOxyh+U8FginXYEtnkEjehuw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
That is not a thread. Linux man clone right at the start …
“clone, __clone2, clone3 - create a child process”
What you want is pthread_create (or similar)
There’s a bunch of not well documented dragons if you’re trying to treat a
child process as a thread. Use POSIX Threads, as pretty much anytime PG or
anything else Linux based says thread they’re talking about a POSIX Thread
environment.
On Wed, May 3, 2023 at 05:12 Michael J. Baars <
mjbaars1977(dot)pgsql(dot)hackers(at)gmail(dot)com> wrote:
> Hi Peter,
>
> The shared common address space is controlled by the clone(2) CLONE_VM
> option. Indeed this results in an environment in which both the parent and
> the child can read / write each other's memory, but dynamic memory being
> allocated using malloc(3) from two different threads simulaneously will
> result in internal interference.
>
> Because libpq makes use of malloc to store results, you will come to find
> that the CLONE_VM option was not the option you were looking for.
>
> On Tue, 2 May 2023, 19:58 Peter J. Holzer, <hjp-pgsql(at)hjp(dot)at> wrote:
>
>> On 2023-05-02 17:43:06 +0200, Michael J. Baars wrote:
>> > I don't think it is, but let me shed some more light on it.
>>
>> One possibly quite important information you haven't told us yet is
>> which OS you use.
>>
>> Or how you create the threads, how you pass the results around, what
>> else you are possibly doing between getting the result and trying to use
>> it ...
>>
>> A short self-contained test case might shed some light on this.
>>
>>
>> > After playing around a little with threads and memory, I now know that
>> the
>> > PGresult is not read-only, it is read-once. The child can only read that
>> > portion of parent memory, that was written before the thread started.
>> Read-only
>> > is not strong enough.
>> >
>> > Let me correct my first mail. Making libpq use mmap is not good enough
>> either.
>> > Shared memory allocated by the child can not be accessed by the parent.
>>
>> Are you sure you are talking about threads and not processes? In the OSs
>> I am familiar with, threads (of the same process) share a common address
>> space. You don't need explicit shared memory and there is no such thing
>> as "parent memory" (there is thread-local storage, but that's more a
>> compiler/library construct).
>>
>> hp
>>
>> --
>> _ | Peter J. Holzer | Story must make more sense than reality.
>> |_|_) | |
>> | | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
>> __/ | http://www.hjp.at/ | challenge!"
>>
> --
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2023-05-03 12:39:45 | Re: PL/pgSQL doesn't support variables in queries? |
Previous Message | hubert depesz lubaczewski | 2023-05-03 12:31:16 | Re: PL/pgSQL doesn't support variables in queries? |