Re: `message' not outputting the newline "atomically"

[Lars Ingebrigtsen]

Eli Zaretskii <address@hidden> writes:

> There was no reason to rush this to the repository.  Paul raises valid
> concerns, some of which I had as well.  Also, the commit message
> describes something that is very different from the code that was
> actually pushed.

The commit message talked about interleaved outputs, which is exactly
what the patch tries to fix, so I'm not quite sure what you mean here...

> I think a version with a fixed-size automatic buffer and a loop using
> it to write the message in chunks, would be a much cleaner solution
> than allocating the buffer off the heap.

Unless I misunderstood something fundamental here (which is very
possible), this is the function that's run when Emacs is in --batch mode
and some code says `(message ...)'.  I tried to trace the callers to see
that this was the case.  I may not have found them all (users are
message3_nolog and message_with_string), but that does seem to be the
use case.  So this is not an error reporting function, but a bit inside
`message', and I don't think anything that calls `message' could
reasonably expect it to not allocate memory.

> There's also a possibility to use the null byte that we
> always/normally have in strings after the last byte.  'fwrite' doesn't
> need it, so we could replace it with a newline, write the message,
> then replace the newline back with the null byte.  This is somewhat
> hacky, but it eliminates the need for a buffer and a loop.

That's an intriguing idea.  But is there a possibility that the fwrite
would fail in such a way that we'd not get back control in such a way
that we could guarantee that we could replace the newline with a null
byte again?  Especially in a multi-threaded Emacs...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no