public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* sigaction & pthread_sigmask
@ 2008-06-19  5:58 William Ahern
  2008-06-19 11:52 ` Burkhardt, Glenn
  2008-06-20  1:59 ` Ross Johnson
  0 siblings, 2 replies; 11+ messages in thread
From: William Ahern @ 2008-06-19  5:58 UTC (permalink / raw)
  To: pthreads-win32

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: sigaction & pthread_sigmask
  2008-06-19  5:58 sigaction & pthread_sigmask William Ahern
@ 2008-06-19 11:52 ` Burkhardt, Glenn
  2008-06-19 12:15   ` John E. Bossom
  2008-06-20  1:59 ` Ross Johnson
  1 sibling, 1 reply; 11+ messages in thread
From: Burkhardt, Glenn @ 2008-06-19 11:52 UTC (permalink / raw)
  To: William Ahern, pthreads-win32

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

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

[-- Attachment #2: pthreads-timer.tbz --]
[-- Type: application/octet-stream, Size: 8518 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: sigaction & pthread_sigmask
  2008-06-19 11:52 ` Burkhardt, Glenn
@ 2008-06-19 12:15   ` John E. Bossom
  2008-06-19 12:18     ` Burkhardt, Glenn
  2008-06-20  1:29     ` Ross Johnson
  0 siblings, 2 replies; 11+ messages in thread
From: John E. Bossom @ 2008-06-19 12:15 UTC (permalink / raw)
  To: pthreads-win32


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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: sigaction & pthread_sigmask
  2008-06-19 12:15   ` John E. Bossom
@ 2008-06-19 12:18     ` Burkhardt, Glenn
  2008-06-20  1:29     ` Ross Johnson
  1 sibling, 0 replies; 11+ messages in thread
From: Burkhardt, Glenn @ 2008-06-19 12:18 UTC (permalink / raw)
  To: John E. Bossom, pthreads-win32

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

> -----Original Message-----
> From: pthreads-win32-owner@sourceware.org 
> [mailto:pthreads-win32-owner@sourceware.org] On Behalf Of 
> John E. Bossom
> Sent: Thursday, June 19, 2008 8:15 AM
> To: pthreads-win32@sourceware.org
> 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" <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.
> >>
> >>
> >>
> >
> 
> 
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: sigaction & pthread_sigmask
  2008-06-19 12:15   ` John E. Bossom
  2008-06-19 12:18     ` Burkhardt, Glenn
@ 2008-06-20  1:29     ` Ross Johnson
  2008-06-20 11:45       ` Burkhardt, Glenn
  1 sibling, 1 reply; 11+ messages in thread
From: Ross Johnson @ 2008-06-20  1:29 UTC (permalink / raw)
  To: John E. Bossom; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: sigaction & pthread_sigmask
  2008-06-19  5:58 sigaction & pthread_sigmask William Ahern
  2008-06-19 11:52 ` Burkhardt, Glenn
@ 2008-06-20  1:59 ` Ross Johnson
  2008-06-20 21:39   ` William Ahern
  1 sibling, 1 reply; 11+ messages in thread
From: Ross Johnson @ 2008-06-20  1:59 UTC (permalink / raw)
  To: William Ahern; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: sigaction & pthread_sigmask
  2008-06-20  1:29     ` Ross Johnson
@ 2008-06-20 11:45       ` Burkhardt, Glenn
  2008-06-20 11:48         ` drifting
  0 siblings, 1 reply; 11+ messages in thread
From: Burkhardt, Glenn @ 2008-06-20 11:45 UTC (permalink / raw)
  To: Ross Johnson, John E. Bossom; +Cc: pthreads-win32

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: pthreads-win32-owner@sourceware.org 
> [mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson
> Sent: Thursday, June 19, 2008 9:28 PM
> To: John E. Bossom
> Cc: pthreads-win32@sourceware.org
> 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" <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.
> >>>
> >>>
> >>>
> >>
> >
> >
> 
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: sigaction & pthread_sigmask
  2008-06-20 11:45       ` Burkhardt, Glenn
@ 2008-06-20 11:48         ` drifting
  0 siblings, 0 replies; 11+ messages in thread
From: drifting @ 2008-06-20 11:48 UTC (permalink / raw)
  To: pthreads-win32

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


Quoting "Burkhardt, Glenn" <Glenn.Burkhardt@goodrich.com>:

> 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: pthreads-win32-owner@sourceware.org
>> [mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson
>> Sent: Thursday, June 19, 2008 9:28 PM
>> To: John E. Bossom
>> Cc: pthreads-win32@sourceware.org
>> 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" <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.
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: sigaction & pthread_sigmask
  2008-06-20  1:59 ` Ross Johnson
@ 2008-06-20 21:39   ` William Ahern
  2008-06-21  3:49     ` Ross Johnson
  0 siblings, 1 reply; 11+ messages in thread
From: William Ahern @ 2008-06-20 21:39 UTC (permalink / raw)
  To: Ross Johnson; +Cc: pthreads-win32

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: sigaction & pthread_sigmask
  2008-06-20 21:39   ` William Ahern
@ 2008-06-21  3:49     ` Ross Johnson
  2008-09-13 23:40       ` William Ahern
  0 siblings, 1 reply; 11+ messages in thread
From: Ross Johnson @ 2008-06-21  3:49 UTC (permalink / raw)
  To: pthreads-win32

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: sigaction & pthread_sigmask
  2008-06-21  3:49     ` Ross Johnson
@ 2008-09-13 23:40       ` William Ahern
  0 siblings, 0 replies; 11+ messages in thread
From: William Ahern @ 2008-09-13 23:40 UTC (permalink / raw)
  To: Ross Johnson; +Cc: pthreads-win32

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2008-09-13 23:40 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-19  5:58 sigaction & pthread_sigmask William Ahern
2008-06-19 11:52 ` Burkhardt, Glenn
2008-06-19 12:15   ` John E. Bossom
2008-06-19 12:18     ` Burkhardt, Glenn
2008-06-20  1:29     ` Ross Johnson
2008-06-20 11:45       ` Burkhardt, Glenn
2008-06-20 11:48         ` drifting
2008-06-20  1:59 ` Ross Johnson
2008-06-20 21:39   ` William Ahern
2008-06-21  3:49     ` Ross Johnson
2008-09-13 23:40       ` William Ahern

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).