in_channel_of_descr questions

in_channel_of_descr questions

[Christoph Bauer]

Hello,

I have some questions concerning in_channel_of_descr: my program
has a list of sockets. I need the sockets itself for a select-Loop
and an in_channel for the convenient input_line function. At the end,
which one should i close? Just the socket, just the channel or both?
On Windows I tried to create many in_channels, one for each block 
I read. Then I get soon an  "Too many open files in the system" error. 
In win32unix/channels.c I see an _open_osfhandle() call for each 
in_channel_of_descr. On unix the same program runs fine (as expected). 
So is there a different approach needed for windows e.g. close just 
the socket on unix, but close socket and in_channel
on windows? (In any case I'll remove the repeated call of 
in_channel_of_descr...).

Thanks for help,

Christoph Bauer

Re: [Caml-list] in_channel_of_descr questions

[Olivier Andrieu]

Hi,

On Wed, Mar 25, 2009 at 13:37, Christoph Bauer
<christoph.bauer@lmsintl.com> wrote:
> Hello,
>
> I have some questions concerning in_channel_of_descr: my program
> has a list of sockets. I need the sockets itself for a select-Loop
> and an in_channel for the convenient input_line function. At the end,
> which one should i close? Just the socket, just the channel or both?

On unix, you should close either one of them, but not both. The
filedescriptor is shared, so closing the socket
or the channel will close the file descriptor.

> On Windows I tried to create many in_channels, one for each block
> I read. Then I get soon an  "Too many open files in the system" error.
> In win32unix/channels.c I see an _open_osfhandle() call for each
> in_channel_of_descr. On unix the same program runs fine (as expected).
> So is there a different approach needed for windows e.g. close just
> the socket on unix, but close socket and in_channel
> on windows? (In any case I'll remove the repeated call of
> in_channel_of_descr...).


yes on windows, you need to close the channel. Calling
in_channel_of_descr will indeed call _open_osfhandle()
which allocates an integer fd in the C runtime to represent the Win32
handle. If you close the socket and not the channel, this CRT fd stays
allocated and you eventually run out of fd. If you close the channel,
the CRT fd will be closed, and that will close the Win32 handle too.

-- 
  Olivier