[m-dev.] Interleaved output in hlc.gc.par
Paul Bone
paul at bone.id.au
Thu Sep 17 18:14:20 AEST 2015
On Thu, Sep 17, 2015 at 05:55:47PM +1000, Peter Wang wrote:
> On Thu, 17 Sep 2015 17:01:59 +1000, Paul Bone <paul at bone.id.au> wrote:
> > On Thu, Sep 17, 2015 at 05:00:27PM +1000, Peter Wang wrote:
> > > On Thu, 17 Sep 2015 16:36:42 +1000, Paul Bone <paul at bone.id.au> wrote:
> > > >
> > > > Should a user reasonably expect calls to io.format to be atomic with respect
> > > > to the IO state? I ask because this creates an inconsistency.
> > >
> > > I don't think so. It is the user's responsibility to serialise any
> > > concurrent uses of the stream. It's not specific to io.format.
> > > Two threads calling write_string may produce output with interleaved
> > > characters, e.g. "Hweolrllod !"
> >
> > Oh,
> >
> > 1) How can users control this for cases when they need to?
>
> Use one of the synchronisation primitives, e.g. thread.semaphore
>
> > 2) Why are we writing character by character?!?!
>
> We call vfprintf in C, and we can do because there happens to be no
> difference between the internal string representation and the external
> representation (for now). Apparently POSIX requires that by default
> stream operations are atomic so, on some platforms, for some operations,
> we would get that atomicity "for free".
Oh cool, I didn't get this from reading the man pages. Although my search
of the pthreads man-page was rather quick.
> It was a slightly bad example, but if we look at the C# implementation
> it can write character by character to perform newline translation.
I don't mind character by character when you write into a buffer. For a
moment I was worried that the calls to the c library where character by
character (I know libc does buffering, but still).
Anyway, now that I've checked Mercury is not writing character by character.
So how can you get interleaved output such as "Hweolrllod !"?
--
Paul Bone
More information about the developers
mailing list