[erlang-questions] Singleton question or design question for transfer file test program

[Bill Durksen]

I am building an Erlang program that copies files between distributed nodes.

- the design calls for a Singleton object (or some mechanism) to store a 
IoDevice value, call it "FdRead", that was returned from a file:open() 
call.
   Similarly, I will need to store an "FdWrite" IoDevice value as well.
- the one Erlang process for Reading a file will be sending N 1024-byte 
blocks to the Erlang process for Writing a file.
- eventually these will distributed nodes, where each Sent Block will be 
a single event, as well as each Received Block
- it works for the first block, but I haven't figure out how to keep the 
IoDevice values from one read or write event to the next.
I looked at the ets system for storing data in tables and tried a few 
experiments, but wasn't able to successfully store an IoDevice type in 
an ets table.

My backup plans are:
   b) throw away the blocking design and just read then entire file in 
one shot.
        Same thing for writing.
   c) close and re-open the files (increase block size)
       i.e. When writing:
            - for the first block create: write and save,
            - and for the remaining blocks: do append and save
        However the reading version may have performance issues, it 
would be something like this:
            - for the first block open, read and send
            - and for the remaining blocks, open, scan to last block 
sent + 1, read and send

I am looking for answers to the questions below:
   1. How can I store an IoDevice type in ets?
   2. Is there a way to create Singleton objects in Erlang other than 
using ets?
   3. If I want to keep the N blocks design, and also avoid re-opening 
the files being read/written each time,
        can I use have a "curried" function for receiving messages from 
a distributed node?
       This last idea just occurred to me, so I put it down in question 
form.
       When I have time, I will go back and investigate this idea.

Thanks,
Bill