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
