getting a Binary module into the standard libs
Hal Daume III
hdaume@ISI.EDU
Tue, 3 Dec 2002 09:46:21 -0800 (PST)
Does flushByte n flush to the next 2^n bit or byte?
--
Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On 14 Nov 2002, Alastair Reid wrote:
>
> > 2) The proposals for flushByte, as I see it, are:
>
> > a) flushBytes h n aligns the stream to the next 2^n byte (bit?)
> > boundary
>
> I think this is the right one to do. It would probably only be used
> with n=8,16,32 but I doubt the extra generality will cost anything.
>
> > b) flushBytes h m n aligns the stream such that the position p
> > satisfies (p = n) mod 2^m
>
> I mentioned this style of interface but I doubt we'd need it in practice.
> If we do, it can always be added later as a separate function.
>
>
> > 3) I think we can all agree that we should buffer BinIOs. There are
> > a few questions, given this:
>
> > a) Should multiple threads be allowed to write the same BinHandle
> > simultaneously? If not, is an error thrown or is the behiour just
> > left "unspecified"?
> > b) Should multiple threads be allowed to read from the same
> > BinHandle simultaneously? If not, ...
> > c) Should one thread be allowed to write and another to read from
> > the same BH simultaneously? If not, ...
>
> I believe GHC has a reader-writer lock on Handles so the answer is
> that one thread blocks if another is already using it in a conflicting
> way.
>
> Basically, I suggest doing whatever normal file Handles do.
>
> > That said, we probably need a dupBin function as Simon suggests. I
> > must say here that I don't know enough about how Handles are
> > implemented in GHC to know where to start on this. I know that they
> > are already MVars of Handle__s which basically hold the file pointer
> > and some other stuff, but I don't know what would need to be done to
> > accomplish such a dupBin function.
>
> Again, this should do what normal file Handles do - and code can be
> stolen/shared to make this work.
>
>
> --
> Alastair
>