getting a Binary module into the standard libs
14 Nov 2002 01:50:45 +0000
> 2) The proposals for flushByte, as I see it, are:
> a) flushBytes h n aligns the stream to the next 2^n byte (bit?)
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
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.