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