[Sigsafe-devel] Re: from the slashdot thread

[Scott L. <sl...@sl...>]

On Feb 19, 2004, at 12:20 PM, Shantanu Bhardwaj wrote:

> Hi,
>
> 		you mentioned something about needing help with your project, i just 
> glanced through the home page but id like to help, so if you can give 
> me some more information to make a decision. what kind of help do you 
> need  .... whats done ... whats to be done etc etc ...

Hey,

(I've cc'd this to the mailing list; I hope you don't mind.)

Glad to hear from you, especially so quickly. What's done:

- the Linux/x86 and Darwin/ppc (OS X / Power Macintosh) implementations 
appear to mostly working
- the race condition checker works on Linux/x86
- good code organization, some comments

What needs to be done:

- additional platforms.

I've got (and you can have) access to oodles of platforms: systems 
running Linux/alpha, Linux/ia64, HP-UX/PA-RISC, Solaris/sparc, 
NetBSD/alpha, NetBSD/x86, FreeBSD/x86, OpenVMS/alpha, 
Windows+Cygwin/x86, and probably others I'm forgetting. (All of these 
through SourceForge's compile farm or HP's test drive.)

There are notes in the top-level README about porting to new platforms. 
If they're not clear (and they're probably not), feel free to ask 
anything.

It's kind of fun to write the assembly. And it's easier than you might 
think to find the necessary information. For the open source platforms, 
you can look at the libc source code. Processor manuals. Google helps a 
lot. And if all else fails, you can try something like "disassemble 
read" in the debugger to find out how libc does it.

It's also very rewarding to see the race condition checker and 
microbenchmark tell you with certainty that your code is working as 
intended. With a lot of projects, it's not so clear-cut.

- case studies.

Example 1: Apache uses a way of implementing socket timeouts that I bet 
is really slow (though correct), especially on platforms like Darwin 
that have slow system calls. I'd like to try adapting their code to use 
sigsafe and see what effect it has on performance. Even if they don't 
accept the code, something like "we modified the world's most powerful 
webserver to use sigsafe and found a XX% performance increase on 
platform X" would be a powerful statement.

Example 2: In my atoms project, I have a signal document that mentions 
use of signals in FreeBSD userspace. I basically did a

     $ find . -name '*.[ch]' | xargs egrep '\<(signal|sigaction)\>'

and started marking down what they did with signals and whether I 
thought it was safe or not. It'd be nice to finish that (with the same 
terminology as everything else) and provide patches to make everything 
safe.

- documentation! I've started a little bit, but from the responses I've 
gotten so far, I need a lot more. So I'd like to present the 
information in a lot of different ways:

1. an introduction section that explains all the concepts and goes over 
a few of the patterns in depth. (This is started, but it doesn't 
mention lots of things: realtime signals, blocked signals, 
thread-directed vs. process-directed signals, asynchronous vs. 
synchronous signals.)

2. a pattern reference showing patterns you might find in existing code 
and good/bad things about them related to safety, portability, ease of 
use, etc. (Also started, but I wrote it _before_ the introduction 
section; it will have to at least be updated to use the same 
terminology and style.) Maybe names for each pattern and a table up 
above with really simplified versions of these notes.

3. a more goal-based reference. Stuff like "I want to wait for either a 
keyboard interrupt or a child to exit, how should I do that?" with a 
preferred method or two, either stated again or just through links to 
the pattern reference.

4. doxygen docs on each relevant "normal" system call. Both links to 
the relevant standards (largely the Single UNIX Specification version 
3) and additional notes. The setitimer manual page, for example, 
doesn't even bother to mention that alarms are directed to the 
_process_, not an individual thread. That's a huge difference, and it 
would be nice to have it actually said _right_there_.

5. performance graphs. I've got a benchmark for it, but it would be fun 
to make an actual graph with gnuplot on various platforms. And useful - 
it would give people a visual idea of how sigsafe compares, and how 
important system call overhead is on various platforms.

6. a couple other tables, like showing different platform 
characteristics (if it uses SA_RESTART by default, if it supports the 
realtime extensions, etc.), a copy of the list of async signal-safe 
functions from SUSv3, etc.

If you feel like you know enough to write any of these sections, great. 
If you don't, that makes your services as a proof-reader that much more 
valuable - I'm trying to explain things, and I can't know if I've 
accomplished that if everyone proof-reading already understands the 
material.

I'd like the documentation to become the authoritative reference for 
how to use signals well, useful even without the sigsafe code.

>
> -Shantanu

Thanks,
Scott