Обсуждение: Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use threads
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. -- 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, Pennsylvania19073
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. -- 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, Pennsylvania19073
--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
Larry Rosenman wrote: > > 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? I have disabled the threading option for that platform. If someone else wants to work with Larry and the community on a solution, feel free. I am done for now, no matter how much Larry "STRENUOUSLY" objects. -- 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, Pennsylvania19073
--On Monday, March 22, 2004 12:33:56 -0500 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> > 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? > > I have disabled the threading option for that platform. If someone else > wants to work with Larry and the community on a solution, feel free. I > am done for now, no matter how much Larry "STRENUOUSLY" objects. > Why so nasty? If you didn't know, I was RIF'd from Internet America on Friday, and have some free time available to code for a bit. I really, really, really want to see threads enabled for libpq for this platform, especially since SCO will be distributing it at some point in time. What code do we need? 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
Larry Rosenman <ler@lerctr.org> writes:
> I really, really, really want to see threads enabled for libpq for this
> platform, especially since SCO will be distributing it at some point in
> time.
I think very few of the folks on this list will see that as a reason
why they should expend any effort; more likely the opposite.
If you can fix it yourself in a reasonably non-intrusive way, we'll take
the patch ... that's about the extent of the cooperation you can expect.
regards, tom lane
Tom Lane wrote: > Larry Rosenman <ler@lerctr.org> writes: > > I really, really, really want to see threads enabled for libpq for this > > platform, especially since SCO will be distributing it at some point in > > time. > > I think very few of the folks on this list will see that as a reason > why they should expend any effort; more likely the opposite. > > If you can fix it yourself in a reasonably non-intrusive way, we'll take > the patch ... that's about the extent of the cooperation you can expect. My big problem is that Larry doesn't have realistic balance in determining how we are to spend our time. Basically, if threading isn't working in CVS for his platform, it is a crisis, and he thinks it should be a crisis for us too, and will complain continuously until it is fixed. (This has been the pattern in the past.) I have no desire to work that way. I, and Tom (I think) suggested that we wait to see what other platforms need this kind of fix before deciding on a solution. However, Larry is obviously not satisfied with that, so he is complaining. Last I looked, I was here to work for the community, based on the community priorities, not Larry's. -- 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, Pennsylvania19073
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> I really, really, really want to see threads enabled for libpq for this >> platform, especially since SCO will be distributing it at some point in >> time. > > I think very few of the folks on this list will see that as a reason > why they should expend any effort; more likely the opposite. > > If you can fix it yourself in a reasonably non-intrusive way, we'll take > the patch ... that's about the extent of the cooperation you can expect. would a dlsym-based solution be accepted? I.E. wrap the pthread_* calls in libpq, and if the real ones are present, use them, else return a static variable? > > regards, tom lane -- 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
Larry Rosenman <ler@lerctr.org> writes:
> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <tgl@sss.pgh.pa.us>=20
> wrote:
>> If you can fix it yourself in a reasonably non-intrusive way, we'll take
>> the patch ... that's about the extent of the cooperation you can expect.
> would a dlsym-based solution be accepted? I.E. wrap the pthread_* calls
> in libpq, and if the real ones are present, use them, else return a static=20
> variable?
I can't tell from that description if the idea meets the "non intrusive"
test or not. How many places would you have to touch? How exactly are
you going to tell "whether the real ones are present"?
regards, tom lane
--On Monday, March 22, 2004 13:15:15 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane >> <tgl@sss.pgh.pa.us>=20 wrote: >>> If you can fix it yourself in a reasonably non-intrusive way, we'll take >>> the patch ... that's about the extent of the cooperation you can expect. > >> would a dlsym-based solution be accepted? I.E. wrap the pthread_* calls >> in libpq, and if the real ones are present, use them, else return a >> static=20 variable? > > I can't tell from that description if the idea meets the "non intrusive" > test or not. How many places would you have to touch? How exactly are > you going to tell "whether the real ones are present"? I'll gen up a patch this week and present it for review. Basically the 3 pthread_* calls that were added for thread-safe pipes would be wrapped, and dlsym returning NULL would mean the real ones are not present, per the note I got back from Dave Prosser of SCO, as well as the paper Jonathan Schilling pointed me to, that I posted the URL to on Friday before my world got rocked. 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