On Thu, 23 Jul 2009 11:12:56 -0700 Garrett D'Amore wrote: >Gordon Ross wrote: >>> Don Cragun wrote: >>> >>>> The one-pager for this project says (in section 3.6) that it doesn't >>>> duplicate core Solaris components. But the description of the Pth >>>> library provided by this case sure sounds like it is trying to duplicate >>>> the behavior of the Solaris pthread library and major chunks of basic >>>> libc functions like read[v] and write[v]. >>>> >>>> Why shouldn't this be considered a duplication of the core Solaris POSIX >>>> threads features even though it adds a "pth_" to the front of a bunch of >>>> standard function names? >>>> >>>> - Don >>>> >>> The Pth library is a secondary dependency, so I answered the question with >>> the main code (GnuPG) in mind. That said, yes it is a bit of duplication. >>> However, the code will not work without it and because some of the code is >>> GPLv3, we cannot modify it to remove the dependency. >>> >>> -Wyllys >>> >> >> I can understand the desire to avoid modifying GnuPG, but if I understand >> this proposal correctly, we'll be rolling in a new threads implementation >> (the "Pth" thing) just to avoid that. Seems unfortunate. >> >> Could we instead be a little more creative and come up with some sort of >> Pth-compatible "shim" library built on top of Solaris threads? >> (Sorry, I admit I know nothing of Pth or how hard this might be.) >> >> There are lots of benefits to using real Solaris threads, such as >> good support for multi-thread debugging, etc. >> >> Gordon >> > > Note that the case was approved yesterday at PSARC as specified. > > I gave the project my +1 on the understanding that GNU Pth is required > for portability reasons, and used by more projects than just this one. > > I would support efforts to either convert this project to native Solaris > threads, or to enhance GNU Pth to "wrap" native threads, but neither > effort is part of this project's proposal, and IMO fall out of scope. > > - Garrett
Garrett, My concern when I was reading the case materials is the gross inefficiency that apps built on Solaris using the pth library are going to suffer. We all know that the implementation of POSIX threads on Solaris systems is one of the best (if not THE Best) on any POSIX-, UNIX-, or Linux system in the world. We also know that the Linux threads do not correctly implement POSIX threads. It looks like the pth library is an attempt to provide POSIX semantics at user level on a Linux system. I understand the desire to write portable code to run on Windows, Linux, and UNIX/POSIX systems, and I have no desire to rewrite code that is using the pth library to do that. But I'm guessing that major chunks of the pth library could be replaced by synonym links to Solaris libpthread or Solaris libc routines and skip a lot of unnecessary duplication of effort. I didn't do much digging to see how deep the problem runs, but the GNU man pages for pth_read(), pth_readv(), pth_write(), and pth_writev() just say that these routines provide the semantics required by POSIX for read(), readv(), write(), and writev(). When linking with -lpthread and -lc on Solaris systems you get that directly by calling the system calls with no emulations required. It seems that the project team could improve things considerably by creating a Solaris specific implementation of the pth library to be used by GnuPG with the added benefit of improving any other Gnu application using the pth library when running on Solaris systems. It is a shame that the project team didn't decide to make this part of their project. - Don
