Re: [RFC 0/1] Contributing a compound object to the libpthread

[Zack Weinberg <zackw at panix dot com>]

On Tue, Jun 19, 2018 at 12:28 PM, DJ Delorie <dj@redhat.com> wrote:
> Oleh Derevenko <oleh.derevenko@gmail.com> writes:
>> All the patent texts (except for those that contain sectecy matter)
>> are publicly available from the USPTO or similar corresponding
>> national/international patent management offices.
>
> As Adhemerval noted, it's not the idea we're running into issues with,
> it's the legal framework under which we are allowed to learn about the
> idea.  Welcome to the US legal system, it's a mess, but it's what we've
> got to work with.
[...]

All that you say is true, but also there _is_ a problem with the idea
of adding a novel "compound" synchronization object to libpthread.
Once we add stuff to the GNU C Library, we can never take it out
again, so we actually try _not_ to add things, most of the time.  We
even drag our feet on adding stuff that we know people want!  This
invention of Oleh's, we don't know yet if anyone wants it.

Oleh, because of the legal headaches discussed upthread, I have not
looked at your code at all, so I don't know if it's practical to
distribute this invention of yours as an independent library.  If you
can do that, you should.  This will allow you to work directly and
rapidly with people who are interested in using it to solve problems.
After something like a decade - yes, ten years or more - of experience
with people using it in real applications, _then_ you could come back
and talk to us about boosting it into the C library and probably also
into POSIX.

The only reason not to go this route is if there is some concrete
reason why you _have_ to hook into the internals of libpthread, and in
that case the conversation we should be having is about why that's
necessary and how it could be avoided.

zw