Wyllys Ingersoll wrote:
> I think this whole Pth thread (no pun intended) is pretty much beaten to
> death.
>
> GnuPG will deliver Pth as it stands, we are not modifying it to be a Solaris
> thread wrapper and we are not modifying GnuPG to use Solaris threads. If
> someone wants
> to file an RFE and take on that work themselves later, then so be it, but it
> is
> not a priority and I don't see any risk or danger in putting it back in it's
> current state.
>
Yes, please end this conversation. The case is long since closed, and
further conversations here are not fruitful. Interested parties can
either open a new case (if sufficient material is present to justify
one), or engage in off-line communication.
As a minor aside, one of the things we should look at in whatever new
tools infrastructure we examine will be a way to either "close" a case,
or put it in "moderation mode", to further posting once the current
PSARC chair(s) decide(s) that the conversations have either drifted too
far afield or are no longer useful.
- Garrett
>
> -Wyllys
>
>
>
>
> Nicolas Williams wrote:
>
>> On Mon, Jul 27, 2009 at 02:00:10PM +0100, Darren J Moffat wrote:
>>
>>> Nicolas Williams wrote:
>>>
>>>> But surely there are limits. Having the GNU Pth library on the system
>>>> for other apps to link with is bad. Using the GNU Pth library in GPG is
>>>>
>>> Why is that bad if that is what that upstream FOSS needs ?
>>>
>> It's only bad if on Solaris GNU Pth performs badly or provides different
>> semantics than on other platforms, or if it interacts badly with Solaris
>> threads.
>>
>> At the very least any team trying to integrate GNU Pth into Solaris,
>> compilation links and all, ought to research the matter and document any
>> such shortcomings. Preferably they should also have to fix such
>> shortcomings, if there are any.
>>
>> I've no objection to GNU Pth itself, unless its API is fundamentally in
>> conflict with Solaris threads.
>>
>> To save us a few e-mail round-trips I looked at GNU Pth just now and I
>> have the following observations:
>>
>> - GNU Pth includes a pthread_* implementation. It would be bad for
>> these symbols to conflict with libc's -- the very least that must be
>> done before we deliver libpth.so is make sure that not such conflict
>> arises.
>>
>> The best solution to that problem would be to deliver only a GNU Pth
>> static link archive, not a DSO.
>>
>> - The build system only mentions Solaris 9, not 10, much less
>> OpenSolaris. And the ChangeLog says that --disable-shared is the
>> default on Solaris because Pth segfaults when built as a DSO on x86.
>>
>> The ChangeLog speculates that the segfault is a linker issue, but it
>> may well be a matter of conflicts with libc (or, rather, libpthread,
>> before S10). See previous note.
>>
>> - GNU Pth "uses a M:1 mapping to kernel-space threads, i.e., the
>> scheduling is done completely by the GNU Pth library and the kernel
>> itself is not aware of the M threads in user-space", according to
>> wikipedia. Given this I don't think we should worry about GNU Pth
>> performing worse on Solaris than on other operating systems.
>>
>> Adding concurrency is likely to break some apps, so a replacement for
>> Pth based on POSIX/Solaris APIs should not be taken lightly, but if
>> one were to try, the notes below might be useful. This convinces me
>> that we should deliver GNU Pth with changes only to avoid symbol
>> conflicts with libc.
>>
>> - The pth_* API can be implemented in terms of POSIX
>> straightforwardly, except, _perhaps_, for pth_ctrl(), which deals
>> explicitly with scheduler concepts -- a POSIX-based implementation
>> might have to fake:
>>
>> - PTH_CTRL_GETTHREADS -- should this count non-pth threads?
>> - PTH_CTRL_GETTHREADS_*, PTH_CTRL_GETAVLOAD, PTH_CTRL_FAVOURNEW
>> -- these can't really be implemented in terms of POSIX without
>> additional kernel APIs, I think (but I could be wrong).
>> - PTH_CTRL_GETNAME -- no concept of thread names in POSIX, may
>> need to add a name attribute.
>>
>> - Some Pth thread attributes have no POSIX equivalent (e.g., thread
>> name, time spawned, ...).
>>
>> - Pth event handling can be implemented in terms of POSIX or Solaris
>> APIs such as event ports. Should be straightforward, but not a
>> trivial one-liner for every Pth event function.
>>
>> - Most Pth functions could be implemented as trivial one-or-three-
>> liners that call POSIX and/or Solaris equivalents.
>>
>> Cheers,
>>
>> Nico
>>
>
>
