> David Schwartz wrote:
> > A patch to use 'poll' instead of 'select' where it's
> > available would be a
> > very good idea. Using 'select' to check readiness of a single descriptor
> > that you just opened is about the worst-case scenario for
> > 'select' (because
> > it has to scan through all
Hello,
> >> I hope the OpenSSL maintainers heard this cry (even if it is a small
> >> cry) and will at some point decide to use a better method than select.
>
> This got patched in CVS yesterday for Linux.
I think that this may be ported to hpux too.
HPUX 11.00, 11.11, 11.23 IA/PA has compatible p
Leon wrote:
I hope the OpenSSL maintainers heard this cry (even if it is a small
cry) and will at some point decide to use a better method than select.
This got patched in CVS yesterday for Linux.
David Schwartz wrote:
A patch to use 'poll' instead of 'select' where it's available w
> OK I implemented the sample source code as provided and it works fine.
> Thanks a million! I guess I "must" use this hack. So be it.
> Thanks again for all you're help I learned a lot.
>
> I hope the OpenSSL maintainers heard this cry (even if it is a small
> cry) and will at some point decide t
On Mon, 2006-06-26 at 15:59 +0100, Darryl Miles wrote:
> I do not believe the kernel has any problem with super-large fd_set's
> being passed to it. I believe the kernel will use whatever size its
> given and attempt to access the memory based on the 'maxfd' argument to
> select. If the kernel
Leon wrote:
On Mon, 2006-06-26 at 14:24 +0200, Marek Marcola wrote:
OK weirdness going on here. I've added the RAND_load_file() command to
the beginning of my program and it does not make a difference.
With a 1000 threads I get a call to RAND_poll() only with the first
connection and not with sub
On Mon, 2006-06-26 at 14:24 +0200, Marek Marcola wrote:
> For me seems that if you properly initialize PRNG
> (before creating threads) this may resolve problem.
> I think something like:
> RAND_load_file("/dev/urandom", 1024);
> should be enough.
OK weirdness going on here. I've added the R
> You may look at poll() and epoll() as alternative event wake mechanisms
> for IO with large numbers of fds in the working set.
Yes. Either rebuild your entire system and fix this value:
> /usr/include/bits/typesizes.h:#define __FD_SETSIZE1024
or use poll.
You'll probably find po
select() has a limit on how big the descriptors can be, otherwise it
crashes.
/r$
--
SOA Appliances
Application Integration Middleware
__
OpenSSL Project http://www.openssl.org
User Suppo
Hello,
> > The select is part of the OpenSSL implementation. I specifically avoided
> > the select() by going multi threaded and here I am sitting with a select
> > problem (I think) due to the OpenSSL library.
> >
> > I want to stay away from hacking the OpenSSL library.
> Sorry for misundestandi
Hello,
> On Mon, 2006-06-26 at 12:46 +0200, Marek Marcola wrote:
> > Or resolution for this problem may be defining new data type
> > "my_fd_set", replacing FD_* macros, and use this new data type in
> > select() with cast to fd_set.
>
> The select is part of the OpenSSL implementation. I specific
On Mon, Jun 26, 2006 at 12:25:09PM +0200, Leon wrote:
> On Mon, 2006-06-26 at 11:44 +0200, Bodo Moeller wrote:
>> What is the file descriptor number that you observe during these
>> calls?
> The file descriptor is 1507 which seems correct since each thread opened
> a socket.
>> Can a single-thre
Darryl Miles wrote:
But I can see your point now, if it is an OpenSSL problem you are pretty
much stuck. For example if OpenSSL uses select() to sleep for
/dev/random but your application is already into the 1500th active file
descritor. Then OpenSSL is pretty much hosed for using select() in
Leon wrote:
$ grep __FD_SETSIZE /usr/include/bits/*.h
/usr/include/bits/typesizes.h:#define __FD_SETSIZE1024
This is the maximum number of fd's the "fd_set" type holds by default.
Maybe it would be possible to stop the crashes and override this with
some ugly stack paddings:
I
On Mon, Jun 26, 2006, Leon wrote:
> > $ grep __FD_SETSIZE /usr/include/bits/*.h
> > /usr/include/bits/typesizes.h:#define __FD_SETSIZE1024
> >
> > This is the maximum number of fd's the "fd_set" type holds by default.
> > Maybe it would be possible to stop the crashes and override
On Mon, 2006-06-26 at 03:53 -0700, Girish Venkatachalam wrote:
> Right. If I were you I would use kqueue() on *BSD or
> epoll() which is avail only on 2.6 linux kernels.
>
> I am not sure what you are trying to achieve but it
> may be worthwhile to take a look at libevent by Neils
> Provos as wel
On Mon, 2006-06-26 at 12:46 +0200, Marek Marcola wrote:
> Or resolution for this problem may be defining new data type
> "my_fd_set", replacing FD_* macros, and use this new data type in
> select() with cast to fd_set.
The select is part of the OpenSSL implementation. I specifically avoided
the se
> $ grep __FD_SETSIZE /usr/include/bits/*.h
> /usr/include/bits/typesizes.h:#define __FD_SETSIZE1024
>
> This is the maximum number of fd's the "fd_set" type holds by default.
> Maybe it would be possible to stop the crashes and override this with
> some ugly stack paddings:
If I
Right. If I were you I would use kqueue() on *BSD or
epoll() which is avail only on 2.6 linux kernels.
I am not sure what you are trying to achieve but it
may be worthwhile to take a look at libevent by Neils
Provos as well. It abstracts out select(), kqueue()
and epoll() thus making ur app porta
Hello,
> This is the maximum number of fd's the "fd_set" type holds by default.
> Maybe it would be possible to stop the crashes and override this with
> some ugly stack paddings:
>
> #defined EXTRA_FDS 500
> char padd0[(EXTRA_FDS/8)+1];
> fd_set fdread;
> char padd1[(EXTRA_FDS/8)+1];
Or resolu
On Mon, 2006-06-26 at 03:00 -0700, Kyle Hamilton wrote:
> Does changing the quota of file descriptors available to the program
> modify its behavior? 'ulimit -n -H' should give you your maximum
> number allowed.
Made it more from the start. Set at 10.
> Also, your system may have a limit on t
Krishna M Singh wrote:
We are using the multiple contexts (although not same as thread count
i.e. 10 Contexts for 3 threads).. Select call may be failing as the
default FD_SET_SIZE is 255 on most systems and thus in case u want to
handle 1000 sockets u need to increase the limit.. There is #def i
Does changing the quota of file descriptors available to the program
modify its behavior? 'ulimit -n -H' should give you your maximum
number allowed. Remember that network sockets are considered files as
well. From your description, I'd think that your file limit is around
2048.
Also, your sys
On Mon, 2006-06-26 at 10:46 +0200, Bernhard Froehlich wrote:
> Hmm, another wild shot, could it be that /dev/random runs out of entropy
> and blocks?
> What exactly are the symtoms? Does your application crash or is it just
> hanging?
Sorry but I did post a follow up directly after the initial po
On Mon, 2006-06-26 at 14:31 +0530, Ambarish Mitra wrote:
> > One thing I do not get is: "Each thread has it's own SSL context ".
> Yes I setup the SSL_CTX in each thread. I have also taken it out of the
> threads into main() creating one global context BUT this gives the same
> error.
>
> - Even i
On Mon, Jun 26, 2006 at 08:49:19AM +0200, Leon wrote:
> I tracked the bug with gdb and found that it fails in RAND_poll(),
> called from SSL_accept(), when a new session key is generated. The
> strange thing is that after the file descriptor set is zeroed
> [(FD_ZERO(&fset)] the call [FDSET(fd,&fs
> One thing I do not get is: "Each thread has it's own SSL context ".
Yes I setup the SSL_CTX in each thread. I have also taken it out of the
threads into main() creating one global context BUT this gives the same
error.
- Even if it gives the same error, I think you should persue the route of
cr
Leon wrote:
Thanks for your reply!
Some days back, we had a riot on "select" call usage. You may revisit those
posts to see if it is helpful.
Well, I do not think it is select() since it works for a 1000 threads.
The part that fails is also part of the standard OpenSSL code so I would
Thanks for your reply!
> Some days back, we had a riot on "select" call usage. You may revisit those
> posts to see if it is helpful.
Well, I do not think it is select() since it works for a 1000 threads.
The part that fails is also part of the standard OpenSSL code so I would
not like to change i
Hi
We are using the multiple contexts (although not same as thread count
i.e. 10 Contexts for 3 threads).. Select call may be failing as the
default FD_SET_SIZE is 255 on most systems and thus in case u want to
handle 1000 sockets u need to increase the limit.. There is #def in
some Windows file.
Some days back, we had a riot on "select" call usage. You may revisit those
posts to see if it is helpful.
One thing I do not get is: "Each thread has it's own SSL context ".
I also had a mult-threaded application, and for the entire process, there
was only one context created with SSL_CTX_new. T
31 matches
Mail list logo
