Hi,

At Thu, 7 Nov 2002 14:08:24 +0900,
Jos Backus wrote:
> > Well, your patch makes thread switch impossible while writing
> > to non-blocking IO, doesn't it?  I suspect it's an acceptable
> > restriction, however, cannot decide it.
> 
> Yes; if the fwrite() blocks, no thread switch will be possible because the
> thread-switch signal (VTALRM) is being blocked. This is the lesser of two
> evils, as the alternative means garbled output.

Agree.

> Do you think that perhaps using the approach used on __human68k__ is better,
> i.e. use the patch below patch instead? This incurs some overhead but for my
> application that would be no problem. I still worry about dropping single
> characters this way though.

I haven't considered about that way.  But don't guess this code
is tested enough since September.  In fact, in the case of EOF
is returned by fputc() but false by ferror(), count of written
bytes would be wrong.  Did you worry about this?

# now I'm afraid of fwrite() in marshal.c.


Index: io.c =================================================================== RCS file: /cvs/ruby/src/ruby/io.c,v retrieving revision 1.167 diff -u -2 -p -r1.167 io.c --- io.c 29 Oct 2002 21:35:28 -0000 1.167 +++ io.c 7 Nov 2002 06:34:19 -0000 @@ -377,10 +377,15 @@ io_write(io, str) ptr = RSTRING(str)->ptr; n = RSTRING(str)->len; -#ifdef __human68k__ +#if defined(__human68k__) || defined(sun) do { - if (fputc(*ptr++, f) == EOF) { - if (ferror(f)) rb_sys_fail(fptr->path); - break; + if (fputc(*ptr, f) == EOF) { + if (!ferror(f)) break; + if (rb_io_wait_writable(fileno(f))) { + clearerr(f); + continue; + } + rb_sys_fail(fptr->path); } + p++; } while (--n > 0); #else
-- Nobu Nakada