sigaction & pthread_sigmask

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

sigaction & pthread_sigmask

William Ahern-2
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.


Reply | Threaded
Open this post in threaded view
|

RE: sigaction & pthread_sigmask

Burkhardt, Glenn
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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> William Ahern
> Sent: Thursday, June 19, 2008 1:58 AM
> To: [hidden email]
> 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.
>
>
>

pthreads-timer.tbz (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: sigaction & pthread_sigmask

John Bossom

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" <[hidden email]>:

> 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> William Ahern
>> Sent: Thursday, June 19, 2008 1:58 AM
>> To: [hidden email]
>> 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.
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

RE: sigaction & pthread_sigmask

Burkhardt, Glenn
It's not my code.  I'll see if I can track down the author.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> John E. Bossom
> Sent: Thursday, June 19, 2008 8:15 AM
> To: [hidden email]
> Subject: RE: sigaction & pthread_sigmask
>
>
> 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" <[hidden email]>:
>
> > 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: [hidden email]
> >> [mailto:[hidden email]] On Behalf Of William
> >> Ahern
> >> Sent: Thursday, June 19, 2008 1:58 AM
> >> To: [hidden email]
> >> 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.
> >>
> >>
> >>
> >
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: sigaction & pthread_sigmask

Ross Johnson-2
In reply to this post by John Bossom
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" <[hidden email]>:
>
>> 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: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>>> William Ahern
>>> Sent: Thursday, June 19, 2008 1:58 AM
>>> To: [hidden email]
>>> 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.
>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: sigaction & pthread_sigmask

Ross Johnson-2
In reply to this post by William Ahern-2
William Ahern wrote:
> 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
Please submit the patch. Send it to me directly if it's large and I will
put it up on the FTP site for others to review if they wish.

Regards.
Ross

Reply | Threaded
Open this post in threaded view
|

RE: sigaction & pthread_sigmask

Burkhardt, Glenn
In reply to this post by Ross Johnson-2
Thank you, Ross.  Sorry I wasn't paying closer attention.

The timer code is available here:
http://ftp.gnu.org/gnu/glibc/glibc-linuxthreads-2.5.tar.bz2

The code I posted is from an older code set, but the current is
virtually the same, and is clearly marked with the "GNU Lesser General
Public License".

In any case, I believe that basic facilities like signals and timers
that are bound up in a threads implementation would be a good addition
to pthreads-win32.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Ross Johnson
> Sent: Thursday, June 19, 2008 9:28 PM
> To: John E. Bossom
> Cc: [hidden email]
> Subject: Re: sigaction & pthread_sigmask
>
> 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" <[hidden email]>:
> >
> >> 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: [hidden email]
> >>> [mailto:[hidden email]] On Behalf Of William
> >>> Ahern
> >>> Sent: Thursday, June 19, 2008 1:58 AM
> >>> To: [hidden email]
> >>> 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.
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

RE: sigaction & pthread_sigmask

John Bossom
Sorry for the confusion... I forgot that the LGPL had a different
name in the past....


Quoting "Burkhardt, Glenn" <[hidden email]>:

> Thank you, Ross.  Sorry I wasn't paying closer attention.
>
> The timer code is available here:
> http://ftp.gnu.org/gnu/glibc/glibc-linuxthreads-2.5.tar.bz2
>
> The code I posted is from an older code set, but the current is
> virtually the same, and is clearly marked with the "GNU Lesser General
> Public License".
>
> In any case, I believe that basic facilities like signals and timers
> that are bound up in a threads implementation would be a good addition
> to pthreads-win32.
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Ross Johnson
>> Sent: Thursday, June 19, 2008 9:28 PM
>> To: John E. Bossom
>> Cc: [hidden email]
>> Subject: Re: sigaction & pthread_sigmask
>>
>> 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" <[hidden email]>:
>> >
>> >> 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: [hidden email]
>> >>> [mailto:[hidden email]] On Behalf Of William
>> >>> Ahern
>> >>> Sent: Thursday, June 19, 2008 1:58 AM
>> >>> To: [hidden email]
>> >>> 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.
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: sigaction & pthread_sigmask

William Ahern-2
In reply to this post by Ross Johnson-2
On Fri, Jun 20, 2008 at 11:58:44AM +1000, Ross Johnson wrote:
<snip>
> Please submit the patch. Send it to me directly if it's large and I will
> put it up on the FTP site for others to review if they wish.
>

I punted on per-thread masks (and thus capabilities for pthread_kill(), as
well) because of my particular time constraints in my current project. I
just wanted to be able to call sigwait().

Any advice on safely using thread-local storage, or tolerance for caveats?
I'm concerned about the interrupts arriving before thread-local storage can
be initialized (using the API, as opposed to linker capabilities, the latter
of which I doubt solves the race anyhow). I had initially set out to use STM
(Software Transactional Memory), but my subsequent understanding of the
literature has been that CAS cannot support fixed space STM algorithms (as
opposed to strong LL/SC primitives, which don't exist in the real-world),
but rather require space linear to the number of processes/threads, and thus
dynamic memory. Clearly this poses a problem for async-safety (honestly, I
have no time to try to make DCAS work, and in any event it would fail on
early AMD 64-bit processors, which have no 128-bit CAS operations, and
anything less than 32-bit versioning--because pointers would eat 48 out of
64 bits--isn't exactly a strong solution to the ABA problem.)

I'm inclined to simply document that interrupts which arrive before TLS can
be setup are discarded, and so simply try to grab any per-thread signal mask
from the pthread_t object (I'll need to confirm that TlsGetValue is
lock-free, of course, or make other arrangements). I'm entirely fuzzy on
Microsoft SEH in general, so perhaps there are stronger constraints I can
rely on. (My signal delivery always serializes handler execution, so handler
masks are moot; I wonder if SEH guarantees that anyhow.)

Also, I'll need time to recode my atomic operations and implementations
according to the local code base (including writing
ptw32_InterlockedCompareExchange64; currently I'm using GCC 4.1 intrinsics).
I'll aim for a proper patch by the end of the month or early July. I just
wanted confirmation my time wouldn't necessarily be wasted.

Reply | Threaded
Open this post in threaded view
|

Re: sigaction & pthread_sigmask

Ross Johnson-2
I'm not qualified to comment in detail.

One thing that I can say that may be important for you deciding how much
time you put into this is that a lot of effort has gone into keeping the
library portable and consistent (for performance) across Windows
versions from W95 onward (plus WinCE - or whatever it's called now), and
able to be built using at least the MSVC and GNU compilers going back a
few years (and others if possible) primarily as a C language library,
i.e. without exception handling. Although mildly discouraged, it can be
built easily with C++ EH, or SEH (MSVC only).

Regards.
Ross

William Ahern wrote:

> On Fri, Jun 20, 2008 at 11:58:44AM +1000, Ross Johnson wrote:
> <snip>
>  
>> Please submit the patch. Send it to me directly if it's large and I will
>> put it up on the FTP site for others to review if they wish.
>>
>>    
>
> I punted on per-thread masks (and thus capabilities for pthread_kill(), as
> well) because of my particular time constraints in my current project. I
> just wanted to be able to call sigwait().
>
> Any advice on safely using thread-local storage, or tolerance for caveats?
> I'm concerned about the interrupts arriving before thread-local storage can
> be initialized (using the API, as opposed to linker capabilities, the latter
> of which I doubt solves the race anyhow). I had initially set out to use STM
> (Software Transactional Memory), but my subsequent understanding of the
> literature has been that CAS cannot support fixed space STM algorithms (as
> opposed to strong LL/SC primitives, which don't exist in the real-world),
> but rather require space linear to the number of processes/threads, and thus
> dynamic memory. Clearly this poses a problem for async-safety (honestly, I
> have no time to try to make DCAS work, and in any event it would fail on
> early AMD 64-bit processors, which have no 128-bit CAS operations, and
> anything less than 32-bit versioning--because pointers would eat 48 out of
> 64 bits--isn't exactly a strong solution to the ABA problem.)
>
> I'm inclined to simply document that interrupts which arrive before TLS can
> be setup are discarded, and so simply try to grab any per-thread signal mask
> from the pthread_t object (I'll need to confirm that TlsGetValue is
> lock-free, of course, or make other arrangements). I'm entirely fuzzy on
> Microsoft SEH in general, so perhaps there are stronger constraints I can
> rely on. (My signal delivery always serializes handler execution, so handler
> masks are moot; I wonder if SEH guarantees that anyhow.)
>
> Also, I'll need time to recode my atomic operations and implementations
> according to the local code base (including writing
> ptw32_InterlockedCompareExchange64; currently I'm using GCC 4.1 intrinsics).
> I'll aim for a proper patch by the end of the month or early July. I just
> wanted confirmation my time wouldn't necessarily be wasted.
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: sigaction & pthread_sigmask

William Ahern-2
On Sat, Jun 21, 2008 at 01:48:37PM +1000, Ross Johnson wrote:

> I'm not qualified to comment in detail.
>
> One thing that I can say that may be important for you deciding how much
> time you put into this is that a lot of effort has gone into keeping the
> library portable and consistent (for performance) across Windows
> versions from W95 onward (plus WinCE - or whatever it's called now), and
> able to be built using at least the MSVC and GNU compilers going back a
> few years (and others if possible) primarily as a C language library,
> i.e. without exception handling. Although mildly discouraged, it can be
> built easily with C++ EH, or SEH (MSVC only).

Update: Refactoring my code to better fit the existing codebase was more of
a hassle than I initially thought. Portability is less of an issue than, for
instance, refactoring my existing atomic operations library (which is based
on the proposed C++ standard, stdatomic.h).

I'll ping the list again when I restart work on this sub-project. My window
of time ran out, and I had to move onto other things.