From: Ross Johnson <Ross.Johnson@homemail.com.au>
To: Laura Arhire <laura.arhire@endion-software.com>
Cc: pthreads-win32@sourceware.org
Subject: Re: strange pthread_create cap
Date: Wed, 02 Sep 2009 14:28:00 -0000 [thread overview]
Message-ID: <4A9E80FD.3040409@homemail.com.au> (raw)
In-Reply-To: <4A9E4D93.5050407@endion-software.com>
Hi Laura,
Pthread_create can return EAGAIN for several reasons, all to do with
lack of resources, such as memory allocation (unlikely), or failing to
start the underlying Windows native thread, e.g. due to a lack of
resources there as well.
I don't know Windows well enough but I'm wondering if your listening
server sockets are really closing down, or perhaps just not quickly
enough. What happens if you add a short delay between creating threads,
i.e. opening new sockets?
Also, are you testing on a Windows Server or Windows Workstation? I ask
because, IIRC and if my information is not out-of-date, workstations
have a limit (10) on the number of sockets that can be listening at the
same time.
Ross
Laura Arhire wrote:
> Hello
>
> I'm having some trouble with pthreads-win and sockets, wondering if
> anyone can help. I have a test setup with a loop which iterates a
> number of times. Inside the loop, I create a thread on which I run an
> SSL server socket. After the thread is created, I connect an SSL
> Client socket to the server socket, then disconnect it, disconnect the
> server socket, and issue a pthread_join.
>
> Using this setup (one thread created with pthread_create at any time),
> I cannot create anymore threads after 10-15 such iterations (in rare
> cases - say if I run a 200-iteration loop, I might be able to create
> threads again once I reach iteration 50 or so). I believe this to be
> an issue with my SSL client socket implementation, because everything
> works well if I don't connect a client socket during the iteration. It
> also works well if I use a non-SSL server/client socket.
>
> However, I thought I'd ask here: is there any reason why
> pthread_create would return EAGAIN in such a setup? The handle count
> varies very slightly during the iterations but does not increase over
> the run time. The memory does increase due to my test setup, but at
> the maximum peak it is no where near close to using up all system
> resources.
>
> Can it be some sort of problem with the release of the socket (win
> sockets are not guaranteed to be released as soon as closesocket
> returns) ?
>
> Thank you in advance,
> Laura
next prev parent reply other threads:[~2009-09-02 14:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-02 10:49 Laura Arhire
2009-09-02 14:28 ` Ross Johnson [this message]
2009-09-02 14:36 ` Ross Johnson
2009-09-02 18:28 ` robert kindred
2009-09-02 23:53 ` John E. Bossom
2009-09-03 6:41 ` Laura Arhire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9E80FD.3040409@homemail.com.au \
--to=ross.johnson@homemail.com.au \
--cc=laura.arhire@endion-software.com \
--cc=pthreads-win32@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).