Обсуждение: UnixWare/Threads stuff [repost from March]
This is a re-post, and still the state of things. There were a few posts after this because of my STRENUOUS objection below. I still think we should enable threads somehow on this platform. --On Monday, March 22, 2004 11:14:59 -0600 Larry Rosenman <ler@lerctr.org> wrote: > > > --On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > >> Bruce Momjian wrote: >>> Larry Rosenman wrote: >>> > The a.out (not any library) should be linked with -Kpthread (not >>> > -lpthread). >>> > This will force libthread to be linked in the right order relative to >>> > libc, libC, networking libraries, etc. >>> > >>> > In other words, the entire application either is or is not linked with >>> > threads; it's not a property of an individual library. >>> > >>> > >>> > SO, IF we are using the threads flags, we need to use them on ALL >>> > libpq-using programs, ours or the users. >>> >>> Seems we have a few options for making threaded libpq on Unixware: >>> >>> o remove thread-safe SIGPIPE code, which calls thread library >>> >>> o create a threaded and non-threaded libpq library >>> >>> o add a libpq function that enables threading, and do dynamic >>> linking of thread calls based on that function >>> >>> o Add thread flags to all builds on that platform, including >>> the backend >>> >>> o Add the ability to specify compile/link flags for everything >>> but the backend >>> >>> As I remember, libcrypt used to be required by all libpq builds on >>> various platforms. This seems to be a similar case. >>> >>> I think the last option might be the best. Somehow create different >>> cppflags/libs for the backend and non-backend programs. >> >> One other option is to disable threads on this platform for 7.5 unless >> we find another platforms that need this to use threads. That is the >> direction I will take for the moment. If someone needs a threaded libpq >> on this platform, then can enable threads, compile libpq alone, and >> rename it with a thread extension. > This will be a REGRESSION from 7.4. I object STRENUOUSLY to this tack. > > I want to see threads enabled for this platform since it is a threaded > kernel. > > What do we have to do to get there? What code do I need to write for > y'all? > > LER > >> >> -- >> Bruce Momjian | http://candle.pha.pa.us >> pgman@candle.pha.pa.us | (610) 359-1001 >> + If your life is a hard drive, | 13 Roberts Road >> + Christ can be your backup. | Newtown Square, Pennsylvania >> 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
I don't see a patch in here ... forget to attach it? On Wed, 12 May 2004, Larry Rosenman wrote: > This is a re-post, and still the state of things. > > There were a few posts after this because of my STRENUOUS objection below. > > I still think we should enable threads somehow on this platform. > > > --On Monday, March 22, 2004 11:14:59 -0600 Larry Rosenman <ler@lerctr.org> > wrote: > > > > > > > --On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian > > <pgman@candle.pha.pa.us> wrote: > > > >> Bruce Momjian wrote: > >>> Larry Rosenman wrote: > >>> > The a.out (not any library) should be linked with -Kpthread (not > >>> > -lpthread). > >>> > This will force libthread to be linked in the right order relative to > >>> > libc, libC, networking libraries, etc. > >>> > > >>> > In other words, the entire application either is or is not linked with > >>> > threads; it's not a property of an individual library. > >>> > > >>> > > >>> > SO, IF we are using the threads flags, we need to use them on ALL > >>> > libpq-using programs, ours or the users. > >>> > >>> Seems we have a few options for making threaded libpq on Unixware: > >>> > >>> o remove thread-safe SIGPIPE code, which calls thread library > >>> > >>> o create a threaded and non-threaded libpq library > >>> > >>> o add a libpq function that enables threading, and do dynamic > >>> linking of thread calls based on that function > >>> > >>> o Add thread flags to all builds on that platform, including > >>> the backend > >>> > >>> o Add the ability to specify compile/link flags for everything > >>> but the backend > >>> > >>> As I remember, libcrypt used to be required by all libpq builds on > >>> various platforms. This seems to be a similar case. > >>> > >>> I think the last option might be the best. Somehow create different > >>> cppflags/libs for the backend and non-backend programs. > >> > >> One other option is to disable threads on this platform for 7.5 unless > >> we find another platforms that need this to use threads. That is the > >> direction I will take for the moment. If someone needs a threaded libpq > >> on this platform, then can enable threads, compile libpq alone, and > >> rename it with a thread extension. > > This will be a REGRESSION from 7.4. I object STRENUOUSLY to this tack. > > > > I want to see threads enabled for this platform since it is a threaded > > kernel. > > > > What do we have to do to get there? What code do I need to write for > > y'all? > > > > LER > > > >> > >> -- > >> Bruce Momjian | http://candle.pha.pa.us > >> pgman@candle.pha.pa.us | (610) 359-1001 > >> + If your life is a hard drive, | 13 Roberts Road > >> + Christ can be your backup. | Newtown Square, Pennsylvania > >> 19073 > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 22:14:33 -0300 "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > I don't see a patch in here ... forget to attach it? It was way back in the thread, and this was the upshot of the discussion. See the note I just replied to Bruce with. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749