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. -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
