From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
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 16:10:42 |
Message-ID: | CAEzk6ffV0HLKPBygzaSi+iD8EN15wETnXtCwMGPJqQehKo+rBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 3 May 2023 at 12:11, Michael J. Baars <
mjbaars1977(dot)pgsql(dot)hackers(at)gmail(dot)com> wrote:
> 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.
>
There's an interesting note here
https://stackoverflow.com/a/45285877
TL;DR: glibc malloc does not cope well with threads created with clone().
Use pthread_create if you wish to use glibc malloc.
Geoff
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2023-05-03 16:17:46 | Re: unknown postgres ssl error "could not accept SSL connection: Success" and timeout |
Previous Message | Peter J. Holzer | 2023-05-03 15:54:50 | Re: libpq and multi-threading |