Re: Cleaning up threading code
От | Peter Eisentraut |
---|---|
Тема | Re: Cleaning up threading code |
Дата | |
Msg-id | ee52b872-bcc7-a181-c537-2dc6662308da@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Cleaning up threading code (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Cleaning up threading code
|
Список | pgsql-hackers |
On 10.06.23 07:26, Andres Freund wrote: >> -############################################################### >> -# Threading >> -############################################################### >> - >> -# XXX: About to rely on thread safety in the autoconf build, so not worth >> -# implementing a fallback. >> -cdata.set('ENABLE_THREAD_SAFETY', 1) > > I wonder if we should just unconditionally set that in c.h or such? It'd not > be crazy for external projects to rely on that being set. We definitely should keep the mention in ecpg_config.h.in, since that is explicitly put there for client code to use. We keep HAVE_LONG_LONG_INT etc. there for similar reasons. Another comment on patch 0003: I think this removal in configure.ac is too much: - else - LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS" This could would still be reachable for $enable_thread_safety=yes and $thread_safe_libldap=yes, which I suppose is the normal case?
В списке pgsql-hackers по дате отправления: