Don Cragun wrote:
> 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.
>
I agree with all of your points.
However, we've already established a precedent in many other cases that
FOSS cases can integrate without necessarily taking the same steps that
we would require of software developed internally.
What this says about the level of quality you might or might not be able
to expect for the individual pieces of software is left for the reader
to judge.
That said, I *hope* someone will go back and make a point of fixing GNU
Pth to work well on Solaris if it doesn't already, making use of our
native threads as much as possible. But, again, not *this* project.
- Garrett
