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