Re: sigaction & pthread_sigmask

[Ross Johnson <Ross.Johnson@homemail.com.au>]

The timers code is from the GNU C library, which the comments in the 
included header file says is LGPL, so it would be ok to use.

However, if the contributors to pthreads-win32 were to agree in future 
to change to a license other than the LGPL or GPL then this code would 
need to be completely removed or replaced.

Regards.
Ross

John E. Bossom wrote:
>
> Your contribution has comments that it is licensed under the GNU
> Public License. This, if included in pthreads-win32, would upsurp
> the LGPL license designation of pthreads-win32 and thus prevent
> commercial use of pthreads-win32 (something LGPL permits provided it is
> used as a shared library - use of the static library renders the
> license GPL, though)
> Are you the original author of this code? Would you consider changing
> the license? Have you already published the package as GPL?
>
> Ross, comments?
>
> Cheers,
> John.
>
> Quoting "Burkhardt, Glenn" <Glenn.Burkhardt@goodrich.com>:
>
>> I think so.  Semaphores might seem out of scope, but they're an integral
>> part of concurrent programming.  Signals need to be thread smart, so
>> they're naturally part of a thread implementation.
>> So are timers - attached is a pthreads compatible version of Posix
>> timers, but it's lacking the function of sending a signal to a thread
>> when a timer has expired.
>>
>>> -----Original Message-----
>>> From: pthreads-win32-owner@sourceware.org
>>> [mailto:pthreads-win32-owner@sourceware.org] On Behalf Of
>>> William Ahern
>>> Sent: Thursday, June 19, 2008 1:58 AM
>>> To: pthreads-win32@sourceware.org
>>> Subject: sigaction & pthread_sigmask
>>>
>>> Would it be worthwhile to submit a sigaction, sigwait,
>>> sigprocmask, pthread_sigmask patch? Or are signals strictly
>>> outside the scope of the project?
>>>
>>> I'm working on sigaction and sigwait implementations--using
>>> atomic CAS operations for async-safety--intended for a
>>> portable kqueue library. But the library depends on
>>> pthreads-w32 anyhow, and it would be cleaner to simply patch upstream.
>>>
>>>
>>>
>>
>
>