Mail Archives: djgpp-workers/2003/01/07/14:39:59
Hello.
Gisle Vanem wrote:
[snip]
> I skimmed the 2.04 alpha sources and noticed the '__set_fd_properties()'
> function. What is the main use of this function? The info-doc didn't give
> an overall picture. Can it be used for FSext'ed handles?
The way I understand it: fd_props is used to store information about file
handles that cannot be obtained later using DOS calls.
An example that I can remember is fcntl's F_GETFL operation. We use the
fd_props to discover whether the file was opened in append mode or not and OR
in the appropriate flag - O_APPEND - into the return open mode. (The other
flags - O_RDONLY, etc. - are obtained by DOS calls.)
The code for FSEXT and fd_props in is in src/libc/fsext and src/libc/dos/io.
There's not much of it and it's worth reading. You should be able to use
fd_props for FSEXT-allocated handles. You may want to ensure that no
filesystem functions end up handling your file descriptor, though, by making
the FSEXT handler function just fail for any functions you're not hooking.
> I'm the maintainer of Watt-32 tcp/ip, where sockets are FSext handles. Can
> I use something like this to auto-close a socket? (when last dup'ed socket
> is closed):
>
> char dev_name[20];
> sprintf (dev_name, "/dev/socket/%d", s);
> __set_fd_properties (s, dev_name, 0); /* what's the last arg? */
> __set_fd_flags (s, FILE_DESC_TEMPORARY);
>
> Can it be used (or extended) to make some sort of virtual dir-list of
> "/dev/socket/"?
You can support /dev/socket/* by adding an FSEXT open handler. See:
info libc alpha __FSEXT_add_open_handler
If you have a copy of DJGPP CVS (what will become 2.04 someday), take a look
at the code to support /dev/zero and /dev/full in src/libc/fsext/fse_zero.c.
This copes with multiple references to /dev/zero and /dev/full. Maybe this
will help.
I'm not sure I would use the fd_props mechanism to cope with dup. I would use
some reference from the FSEXT data for each file descriptor to point to some
per-socket block. Then in the per-socket block there would be a reference
count. Every time a file descriptor point to a per-socket block was closed,
I'd decrease the reference count in the per-socket block. If the count reaches
zero, do the socket clean-up.
I don't think FILE_DESC_TEMPORARY does what you want either. This is for
removing physical files on close. OTOH if you have a remove handler for the
socket, you can do what you want. (close will call remove for file descriptors
with FILE_DESC_TEMPORARY set in fd_props.)
Hope that helps.
Bye, Rich =]
PS: Are you subscribed to djgpp-workers or should we CC you on replies?
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -