RE: getting a Binary module into the standard libs

> > BinMem and BinIO differ quite a bit here: for BinMem you can write
> > straight into the array, whereas for BinIO we need a cache 
> - a single
> > byte at the least, but ideally more.  BinMem is the most 
> important case
> > to optimise (for us in GHC anyhow), since BinIO is already 
> significantly
> > slower due to the overhead of the Handle interface.
> 
> Currently the BinIO implementation doesn't do any caching, though,
> right?  I actually rarely use the BinMem implementation, so I would be
> more interested in improving the speed of BinIO.  Presumably, 
> however, the
> Handle actually does buffering, which should take care of a 
> large part of this, right?

The problem is the overhead of the Handle interface.  hPutChar is quite
expensive, because it has to lock/unlock the Handle.

Using a cache in the BinIO implementation would help a lot, but it also
means that you have to keep exclusive access to the Handle while doing
binary operations.  There is already a similar problem, because the
library caches the file pointer outside the Handle, so someone doing an
hSeek on the same Handle will cause the cached version to be out of sync
with the real one.  

Should multiple threads be allowed to access the same BinHandle
simultaneously?  Probably not in write mode, but it might be useful when
reading.  Maybe we could provide

  dupBin :: BinHandle -> IO BinHandle

this is easy enough to implement, and the separate BinHandles could be
used from different threads.

> > There should really be a closeBin function too; it's quite simple to
> > add.
> 
> On files this would flush the current byte then close the file handle,
> right?  What would it do on BinMems (other than flush the byte)?

closeBin can throw away a BinMem.  If it needs to be written to a file,
then we provide writeBinMem.

Cheers,
	Simon