From: Jos Backus <jos@...>
Date: 2002-11-08T16:08:44+09:00
Subject: Re: io_write()/fwrite() and EINTR on Solaris

    Hi,

On Fri, Nov 08, 2002 at 02:10:52PM +0900, nobu.nokada@softhome.net wrote:
> Whichever you like, safe_fwrite() version or fputc() one.  I'm
> not a Solaris user, so couldn't decide which approach is
> better.

OK, to test if the fputc() version works reliably I will modify the
interpreter at work to use fputc() instead of fwrite().

If it works satisfactorily I would prefer that we use the fputc() version on
Solaris instead of the signal-blocking approach, even though it is less
efficient - at least it does not introduce any change in semantics. I should
know in a few days if the fputc() approach is safe (my colleague will complain
if it isn't :) and will report back.

> If configure can detect this problem, it may be better to let
> it do and give an overriding value by an environment variable
> (maybe rb_cv_broken_fwrite?) for cross compile.  Could you
> provide small test code?

Hm, you mean convert my fwrite-bug.c program into a small, self-contained test
program that shows whether the problem exists by exit code? It looks hard, but
I will try and let you know.

> I prefer --with-* options when users have choice, in this case,
> --with-io-write-per-byte or something else would be nice, IMHO.
 
That sounds like a decent alternative to having an automated configure test. I
hope I can come up with such an automated test, please stay tuned.

> # and __human68k__ would be IO_WRITE_PER_BYTE here.

Indeed. #ifdef's in code should test for features, not platforms.

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'