Re: Using the fd's underlying guile fports

[Gary Houston <ghouston@easynet.co.uk>]

| > Could you use a mutex? 
| > 
| > The revealed count indicates whether the port owns its descriptor.
| > If the count is greater than 0 then the descriptor shouldn't be
| > closed when the port is gc'd (currently implemented by not gc'ing the
| > port, but that's not required now.)
| > 
| 
| I don't think a mutex is any use. It's a problem within any single thread:
| at any time where it is possible for the fd to be used directly, it
| mustn't be used by the scheme port code. I want the fd to be legitimately
| borrowed from the port and returned some time later.

I see, you have your own port type and want to keep the FILE * around
in its data structure.  If you can make the FILE unbuffered (using
stdio setvbuf) then the problem isn't any harder than using the file
descriptor from the port directly.  Alternatively if it's only used
for output then flushing it after each use inside the interface would
have the same effect.

There are several procedures already built in to Guile that have this
problem.  e.g., "send" in socket.c.  socket ports are created
unbuffered.  That's one solution to your problem: use an unbuffered
port.  However adding a buffer will give better performance.  A buffer
can be added to a socket port using the Scheme version of setvbuf and
then it's up to Scheme code to call force-output if it wants to
maintain the ordering of bytes after transmission.  For an output-only
procedure like "send" you could flush the port inside the wrapper
before doing anything with the file descriptor (call scm_fflush).

Input procedures are more difficult, there are different things you
may want to do with the port buffers.  I added a drain-input procedure
in the hope that it may be useful for Scheme code that needs some
control over what's happening.