Re: Aim of --enable-thread-safety ?
От | DANTE Alexandra |
---|---|
Тема | Re: Aim of --enable-thread-safety ? |
Дата | |
Msg-id | 44B24B95.8010207@bull.net обсуждение исходный текст |
Ответ на | Re: Aim of --enable-thread-safety ? (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-general |
Hello Martijn, Thank you for your answer. Just to be sure, the "--enable-thread-safety" option allows client libraries, which connect via libpq to a PostgreSQL database, to be multi-threaded, but each "postgres" process launched to etablish the connection is not multi-threaded. Consequently, PostgreSQL can not execute a query in several CPU, the source code of PostgreSQL is not multi-threaded. Is it correct ? Thank you very much for your help. Regards, Alexandra Martijn van Oosterhout wrote: >On Mon, Jul 10, 2006 at 11:47:06AM +0200, DANTE Alexandra wrote: > > >>Hello List, >> >>I wonder if this compilation option is really taken into account as >>PostgreSQL is not multi-threading but multi-processing. >>I have read that without this option, the libpq won't know anything >>about threads and may indeed have problems, but could you explain me how >>this option runs ? >> >> > >It enables thread-safety in client libraries. If you don't do this then >the client libraries will behave strangly when used in multi-threaded >programs. > >As an example, consider the "errno" variable. It's a global variable, >which obviously doesn't work well in multi-threaded programs. When you >enable thread-safety it becomes a thread-local variable. The C library >has a number of things like that (locale, timezone, strtok, etc). > >In modern systems it should always be on for libraries. There's is no >way to guarentee your library won't be used in a multithreaded program >and the cost is marginal. Really, the option should be changed to >default to on. > >Hope this helps, > >
В списке pgsql-general по дате отправления: