Re: [Sigsafe-devel] Re: advogato diary

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

On Feb 17, 2004, at 3:53 PM, Scott Lamb wrote:
> Is that convincing or do I need to do a different benchmark? I suppose 
> I could take a real thread-based webserver and butcher it to double 
> the number of IO system calls it makes. I'm fairly confident I'd find 
> a substantial change in throughput.

Or fix it to use half as many system calls. I just remembered that 
Apache always does a select() before read() with their APR read with 
timeout code. This would probably be a good case study for sigsafe. I 
might just do it...

>> Also, I think you might be wrong about the setjmp() trick (which 
>> would be the proper trick for read()), read() will return EINTR only 
>> if the I/O operation did not complete
>
> I've added (since the 0.1.0 release) a test for this to race_checker. 
> And it returns the result I expected - the jump can happen after the 
> system call completes. (With the setjmp() method, it doesn't really 
> use EINTR at all.) I also added some more description of this to the 
> documentation.

Ahh, now I think I see what you are talking about here. My example of 
the longjmp method checks for EINTR return; that's unnecessary and 
confusing. That path will only be taken if a _different_ signal arrives 
(one which does not jump), which is not what I want to focus on. I've 
removed it from the example.

Thanks,
Scott Lamb