Re: Proposal for Prototype Implementation to Enhance C/C++ Interoperability in PostgreSQL - Mailing list pgsql-hackers
| From | 盏一 |
|---|---|
| Subject | Re: Proposal for Prototype Implementation to Enhance C/C++ Interoperability in PostgreSQL |
| Date | |
| Msg-id | tencent_1B95447F233355703E858DD9@qq.com Whole thread Raw |
| In response to | Re: Proposal for Prototype Implementation to Enhance C/C++ Interoperability in PostgreSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Proposal for Prototype Implementation to Enhance C/C++ Interoperability in PostgreSQL
|
| List | pgsql-hackers |
> It seems extremely specific to one particular C++ implementation
To perform a force unwind during longjmp, the _Unwind_ForcedUnwind function is used. This function is defined in the [Itanium C++ ABI Standard](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-throw), which is followed by all C++ implementations. Additionally, the glibc [nptl/unwind.c](https://elixir.bootlin.com/glibc/latest/source/nptl/unwind.c#L130) file shows that on all platforms, pthread_exit is also implemented using _Unwind_ForcedUnwind.
Furthermore, the Itanium C++ ABI specification also defines _Unwind_RaiseException as the entry point for all C++ exceptions thrown.
> you've thrown in a new dependency on pthreads
The reason for the dependence on pthread is due to the overloading of _Unwind_RaiseException, which serves as the entry point for all C++ throwing exceptions. Some third-party C++ libraries may create threads internally and throw exceptions.
Overloading _Unwind_RaiseException is done to convert uncaught exceptions into elog(ERROR). If we require that all exceptions must be caught, we can remove the overloading of _Unwind_RaiseException and all pthread dependencies.
The overloading of _Unwind_RaiseException is just a fallback measure to prevent uncaught exceptions from terminating the process. In our code, this path is rarely taken, and once we encounter an exception that is not caught, we will fix the code to catch the exception.
> doesn't this require us to move our minimum language requirement to C++-something?
No, all code has no dependency on C++.
------------------ Original ------------------
From: "tgl@sss.pgh.pa.us"<tgl@sss.pgh.pa.us>;
Date: Sun, May 7, 2023 11:35 PM
To: "盏一"<w@hidva.com>;
Cc: "pgsql-hackers"<pgsql-hackers@postgresql.org>;
Subject: Re: Proposal for Prototype Implementation to Enhance C/C++ Interoperability in PostgreSQL
"盏一" <w@hidva.com> writes:
> The proposed implementation can significantly improve the interoperability between C and C++ code in PostgreSQL. It allows for seamless integration of C++ code with PostgreSQL, without the need for complex workarounds or modifications to the existing codebase.
That'd be nice to have, certainly ...
> I have submitted the implementation on [GitHub](https://github.com/postgres/postgres/commit/1a9a2790430f256d9d0cc371249e43769d93eb8e#diff-6b6034caa00ddf38f641cbd10d5a5d1bb7135f8b23c5a879e9703bd11bd8240f). I would appreciate it if you could review the implementation and provide feedback.
... but I think this patch has no hope of being adequately portable.
It seems extremely specific to one particular C++ implementation
(unless you can show that every single thing you've used here is
in the C++ standard), and then for good measure you've thrown in
a new dependency on pthreads. On top of that, doesn't this
require us to move our minimum language requirement to C++-something?
We just barely got done deciding C99 was okay to use.
regards, tom lane
> The proposed implementation can significantly improve the interoperability between C and C++ code in PostgreSQL. It allows for seamless integration of C++ code with PostgreSQL, without the need for complex workarounds or modifications to the existing codebase.
That'd be nice to have, certainly ...
> I have submitted the implementation on [GitHub](https://github.com/postgres/postgres/commit/1a9a2790430f256d9d0cc371249e43769d93eb8e#diff-6b6034caa00ddf38f641cbd10d5a5d1bb7135f8b23c5a879e9703bd11bd8240f). I would appreciate it if you could review the implementation and provide feedback.
... but I think this patch has no hope of being adequately portable.
It seems extremely specific to one particular C++ implementation
(unless you can show that every single thing you've used here is
in the C++ standard), and then for good measure you've thrown in
a new dependency on pthreads. On top of that, doesn't this
require us to move our minimum language requirement to C++-something?
We just barely got done deciding C99 was okay to use.
regards, tom lane
pgsql-hackers by date: