Re: very obscure problem, help needed

[Dale P. Smith]

Dirk Herrmann wrote:
> 
> On Thu, 2 Nov 2000, Dale P. Smith wrote:
> 
> > The response from Dirk about flushing buffers first before forking will
> > probably fix your problem.
> 
> If that is true:  Shouldn't guile itself do the flushing then?  I don't
> think that anyone would intentionally leave the buffers unflushed - it's
> an implementation detail anyway how much output is kept in buffers, isn't
> it?  In other words:  Are there any situations at all where you would want
> to keep buffers unflushed?  If not, we should flush automatically and
> don't leave it to the user.  Otherwise other people will at some time run
> into the same problems as David.

Make a lot of sense to me.  How do other scripting languages deal with
the issue?

Perl doesn't flush. My "perlfunc" man page has this on fork:
               Note: unflushed buffers remain unflushed in both
               processes, which means you may need to set $|
               ($AUTOFLUSH in English) or call the autoflush()
               method of IO::Handle to avoid duplicate output.
and:
               Note that if your forked child inherits system
               file descriptors like STDIN and STDOUT that are
               actually connected by a pipe or socket, even if
               you exit, then the remote server (such as, say, a
               CGI script or a backgrounded job launced from a
               remote shell) won't think you're done.  You should
               reopen those to /dev/null if it's any issue.

*Is* there any reason why we would want the unflushed behavior?  The
only thing I can think of is if you encounter some kind of error or
something and you want to throw away the pending output before dealing
with the error.  Maybe for efficiency?  Your child process doesn't
generate any output and you want to keep your output in buffer sized
chunks?  I dunno.

-Dale

-- 
Dale P. Smith
Altus Technologies Corp.
address@hidden
400-746-9000 x309