Geoff Thorpe wrote:
> > I'm writing a server that will often have more than 1024
> > file descriptors open. That means that any code using
> > stdio might fail, since stdio.h can't handle any
> > fd's higher than 1024 on some systems.
>
> That only gives you a limit *per-process*. :-)
True - but when you're using multiple threads instead of
multiple processes, it starts to hurt.
> > has this issue been discussed before?
>
> Not that I recall, but please do. I'm curious how wide-spread the need for
> programs are that run more than 1024 file descriptors and can't spread
> them across processes (usually at those volumes you end up forking from a
> master process that holds open IPC connections to the "children"). I'm
> particularly curious if these apps are also doing SSL (which is usually
> *way* too fat and blocky to want to cram that much into a single process).
I'm doing it; right now, I have a single network thread doing all normal
networking *and* SSL; after I write the load tests that demonstrate
how woefully inadequate that is :-), I'll split that into two threads:
one for doing the SSL accept / connect stuff, and one for all other
networking including bulk SSL. (I have yet other threads for disk I/O.)
Hope that will suffice, otherwise I get to do a little refactoring, or worse.
> Anyway, in principle, I can't see why this would be a big obstacle to
> using a non-stdio interface - you should just need to create alternative
> BIOs (or BIO_METHODs, more to the point). Mind you, I've never felt the
> need to do that nor even use the network-aware BIOs at all myself, so I
> take what I say with a dose of salt. Have you tried doing this yet?
Where this came up for me was in PEM_read_bio_RSAPrivateKey(BIO *, ...)
I haven't gotten into the PEM stuff much yet. Maybe there are
ways of using them without BIO's, but hey, if it's easy to fix
bss_file.c, maybe I'd do that.
The real issue that brought this up was a file descriptor leak in
my code :-) Once I fix that, I can ignore this issue for a little
while longer!
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
