This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Using the fd's underlying guile fports



> The library I'm writing glue code for has a trace feature which results in
> a low-level trace being written to a specified (FILE *) passed in. To make
> this flexible I would like to be able to accept any fport as an argument
> to the trace function. That way trace could be done to any stream very
> easily, without my having to write code to do fopen popen etc.
> 
> However there is a potential problem with the port being written to or
> read from by guile whilst it's underlying fd is written to from the
> third-party library.

I'm not sure I understand the whole picture, but I'm not sure that
such locking is appropriate.

Is this any different from sharing a port between two Scheme modules,
where one wants to produce tracing output?  Is this any different from
two modules sharing any data structure which is typically manipulated
destructively?

Generally, the library documentation just says, "After you give me
this port/data structure/lemon pie, I will write to it/tweak it/eat it
any time I please, so back off."  As long as the consequences of
breaking the rules are simply incorrect output, and not a crash,
that's generally okay.

But a classy library copies the object, if that's not too expensive.
Which is much the effect you'd get by extracting the FD, dup'ing it,
and calling fdopen on it.  (You need the dup so that closing the
original port doesn't close the library's FILE.)

I don't think buffering is really an issue here --- it may make the
results stranger, but they're already wrong the instant the client
writes anything to the port.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]