Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Thien-Thi Nguyen]

() Andy Wingo <address@hidden>
() Fri, 12 Feb 2010 21:48:20 +0100

   I wonder as well; but if the API works as advertised, then the
   file must be deleted, whether fclose(3) is called or not; so I
   guess this part of things works out fine.

If you s/file must be deleted/filename must be removed from the
directory listing/, then yes.

However, i do think that Guile MUST call fclose(3), so as to avoid
starving long-running processes that call tmpfile(3) many times of
file descriptors.  Unfortunately, i don't see a portable way of
verifying this (e.g., doing "watch lsof" depends on both watch(1)
and lsof(8)), otherwise i'd have included a test case.

   If the FILE* is never written to then we don't
   have buffering problems either.

Right.  We "faithfully maintain" the abstraction presented by the OS.
It's true that we could fool around w/ FILE* but that:
- is inelegant;
- creates more work (blech);
- breaks the "spirit" of the abstraction (as i see it).

   I think ttn/wip-TOPIC is a fine convention.  I'm also fine with
   simply wip-TOPIC.  But either way works for me.

   Regarding our reservations / impedance mismatches, I think the
   best thing for all would be for you to hack away as you see
   fit, commit to branches, and we give feedback on the branches.

OK, i will change my current MO from posting patches to updating
ttn/{wip-}foo branches plus signalling to the mailing list for review.
(I will continue to ask WDYT-type questions, in any case.)

I have some git-non-expert questions, too (this is the first
project in which i use "git push"), but i'll start another thread
for those.

thi