473,320 Members | 1,820 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Asynchronous Programming

I'm trying to determine if I need to make my application multi-threaded, or
if it can be done with asynchronous programming. I realize that asynch calls
do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP,
does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve
Nov 15 '05 #1
48 5333
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:O6****************@TK2MSFTNGP09.phx.gbl...
I'm trying to determine if I need to make my application multi-threaded, or if it can be done with asynchronous programming. I realize that asynch calls do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP,
does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve


Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download..._threading.pdf

Erik
Nov 15 '05 #2
"Steve - DND" <steve!@!digitalnothing.com> wrote in
news:O6**************@TK2MSFTNGP09.phx.gbl:
I'm trying to determine if I need to make my application multi-threaded,
or if it can be done with asynchronous programming. I realize that
asynch calls do create a new thread in the background, but when they
come back, they return to the thread that launched them, is that
correct? If I go multi-threaded, then I just need to spawn a new thread
for each new connection, right?
My advice is unless its just one isolated task - such as a single file read
or other, thread it. Your code will be much cleaner.
What I'm doing here is making a service that accepts connections via
TCP, does some stuff, and then returns a response. Would my best bet be
to go asych or multi-threaded? Any articles on either or both would be
much appreciated.


Multi threaded. Your code will be much cleaner, and more maintainable.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #3

"Erik Frey" <er*******@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP11.phx.gbl...
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:O6****************@TK2MSFTNGP09.phx.gbl...
I'm trying to determine if I need to make my application multi-threaded,

or
if it can be done with asynchronous programming. I realize that asynch

calls
do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP, does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve


Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download..._threading.pdf


One thing I have a question on is scalability performance. I keep reading
that a multi-threaded approach may not necessarily scale very well. How many
threads is too many before the switching starts to kill the app? I will
probably have about 50-75(possibly up to 100) concurrent connections at peak
times. From what I have read, it sounds like this would be too many threads
to create.
Nov 15 '05 #4
Steve,

Check out the ThreadPool Class. It'll handle multiple threads for you
in a much cleaner manner.

Chris R.

"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...

"Erik Frey" <er*******@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP11.phx.gbl...
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:O6****************@TK2MSFTNGP09.phx.gbl...
I'm trying to determine if I need to make my application multi-threaded,
or
if it can be done with asynchronous programming. I realize that asynch calls
do create a new thread in the background, but when they come back,
they return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via

TCP, does some stuff, and then returns a response. Would my best bet be to go asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve


Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download..._threading.pdf


One thing I have a question on is scalability performance. I keep reading
that a multi-threaded approach may not necessarily scale very well. How

many threads is too many before the switching starts to kill the app? I will
probably have about 50-75(possibly up to 100) concurrent connections at peak times. From what I have read, it sounds like this would be too many threads to create.

Nov 15 '05 #5
A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
event and look that up to get your client socket object. You need to use
the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this
in managed code. However, after you do that, you should be able to use the
standard socket and TCPclient send and rec methods as normal. If you will
have many concurrent clients with concurrent send and receives, then using
one thread per client is not really optimal in server design and will be
slower then other designs because of the thread context switches and
contention for shared resources goes up with number of threads.. If many
clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of
this from managed code however.
--
William Stacey, MVP
--
William Stacey, MVP

"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:O6**************@TK2MSFTNGP09.phx.gbl...
I'm trying to determine if I need to make my application multi-threaded, or if it can be done with asynchronous programming. I realize that asynch calls do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP,
does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve

Nov 15 '05 #6
I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for locks,
etc. then actually working. Each thread also gets a smaller quantum time to
do work as more threads are running in the system. So less time each thread
has to work, more context switch time, more contention for locks, etc. I am
not sure the Async read and writes using standard Socket or TCPClient are
much better. AFAICT, if you post reads for all those sockets, it will still
use that many threads from the pool to run the delegates for replies, not
much better as you end up hurding threads and your still using one thread
per client per read/write afaict. And does it queue the Async Reads if the
thread pool runs out of threads (i.e. more then 25) and block on new Async
requests or queue them and let the 25 threads work on the queue? Not sure.
There is some gray area here that would need to be tested. The overhead of
using the system supplied Async abstration is not free either. There a lot
of setup and tear down expense. Doing some informal testing on a circular
queue with one producer and one consumer I get about this each time:
Custom Async get/put: 00:00:10.3593750
Sync get/put: 00:00:01.0937500
CLR Async get/put: 00:00:37.6250000

The System async infrastructor is about 3-4 times slower then doing async
yourself and service the queue with one thread running in a tight loop. The
clr async is really easy, however, and seems to work well.

If perf is key, you may have to resort to overlapped io sockets or
WSAEventSelect and wrap a few pInvoke apis.

--
William Stacey, MVP

"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...

"Erik Frey" <er*******@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP11.phx.gbl...
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:O6****************@TK2MSFTNGP09.phx.gbl...
I'm trying to determine if I need to make my application multi-threaded,
or
if it can be done with asynchronous programming. I realize that asynch calls
do create a new thread in the background, but when they come back,
they return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via

TCP, does some stuff, and then returns a response. Would my best bet be to go asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve


Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download..._threading.pdf


One thing I have a question on is scalability performance. I keep reading
that a multi-threaded approach may not necessarily scale very well. How

many threads is too many before the switching starts to kill the app? I will
probably have about 50-75(possibly up to 100) concurrent connections at peak times. From what I have read, it sounds like this would be too many threads to create.

Nov 15 '05 #7
"Steve - DND" <steve!@!digitalnothing.com> wrote in
news:ux**************@TK2MSFTNGP09.phx.gbl:
One thing I have a question on is scalability performance. I keep
reading that a multi-threaded approach may not necessarily scale very
well. How many threads is too many before the switching starts to kill
the app? I will probably have about 50-75(possibly up to 100) concurrent
connections at peak times. From what I have read, it sounds like this
would be too many threads to create.


Ill post more later - but 100 thread is NOTHING. Dont worry till you get near
500 or more... Even 1000 is ok in most circumstances.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #8
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:eK**************@TK2MSFTNGP09.phx.gbl:
I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller
quantum time to do work as more threads are running in the system. So


Actually thats not correct - its a common misconception. I have to go out to
pay some bills but will post more on this later. Or check your copy of Indy
in Depth for details about this...

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #9
Lay it on me brother :-) As a side note, was not talking about Indy, but
..Net. If the Socket classes BeginX methods do not use the Std Async tech
with the thread pool, I would be interested in that and appreciate the
correction. Thanks!

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:eK**************@TK2MSFTNGP09.phx.gbl:
I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller
quantum time to do work as more threads are running in the system. So
Actually thats not correct - its a common misconception. I have to go out

to pay some bills but will post more on this later. Or check your copy of Indy in Depth for details about this...

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Nov 15 '05 #10
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:Oy**************@TK2MSFTNGP11.phx.gbl:
Lay it on me brother :-) As a side note, was not talking about Indy, but


Yes. I know - its just that I know all about this threading stuff and common
misconceptions because of having to explain it so many times on the Delphi
forums. :)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #11
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:u6**************@tk2msftngp13.phx.gbl:
A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
The problem with this is there is a limit of 64 per call, so you still need
to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.
contention for shared resources goes up with number of threads.. If many
clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of
this from managed code however.


Indy has support for this using fibers. This part is in SuperCore and hasnt
been ported to .net yet. This part will likely have to be unmanaged until
fibers, etc are accesible as managed objects.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #12
"Steve - DND" <steve!@!digitalnothing.com> wrote in
news:ux**************@TK2MSFTNGP09.phx.gbl:
One thing I have a question on is scalability performance. I keep
reading that a multi-threaded approach may not necessarily scale very
Key word is "may not". In most cases, espeically with sockets its fine. In
fact its better.
well. How many threads is too many before the switching starts to kill
the app? I will probably have about 50-75(possibly up to 100) concurrent
It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet. :)

What you will hit before any limits is the process memory limit. You will hit
this at about 1000 threads (There are ways to go higher, but normally you
should not as 1000 threads in one process has other issues).

If you arent going over 200-300 threads, dont even worry about it. That is
unless each one is calculating Pi to the 4 billionth digit.
connections at peak times. From what I have read, it sounds like this
would be too many threads to create.


Not at all. Windows wont even notice that many.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #13
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:eK**************@TK2MSFTNGP09.phx.gbl:
I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller
Not true as people assume.... If they are all active calculating Pi - yes.
But active in this case means "socket activity" then no. The reason for
this is bandwidth.

Lets take a 100 MB ethernet. Calculate its max speed against the CPU. You
will see that it is MANY magnitudes slower than even todays most slothful
of CPUs. Factor in hardward buffers, and software driver buffers and each
thread is activated very rarely in the scheme of things even in a fully
loaded ethernet card.

Beause of this, threads spend most of their time waiting on network calls.
This causes them to be skipped over by the scheduler until their blocking
calls have returned. This reduces the "theoretical" context switching by
many thousands.
quantum time to do work as more threads are running in the system. So
Most thread in this type of system wont reach their quantum because they
will voluntarily sleep first.
less time each thread has to work, more context switch time, more
Nope - because they will switch to threads which are running, which in such
a system most threads on each pass will be sleeping. In fact many of the
switches will be to the idle or system threads.
contention for locks, etc. I am not sure the Async read and writes
using standard Socket or TCPClient are much better. AFAICT, if you post
There are two types of asyncs. The asyncs with windows messages are usually
even slower.

Another factor is the blocking "thunk" to kernel level. But again, only for
advanced systems.

In the scheme of things, what this user describes is a very small system
and he should focus on clean readable code. Performance will be just fine
and there is not need to build and advanced design and muck up his code.
If perf is key, you may have to resort to overlapped io sockets or
WSAEventSelect and wrap a few pInvoke apis.


Problems there too. :)

IOCP is the only TRUE fast way, and it has a TON of problems that should be
avoided and only used as a LAST resort.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #14
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:Oy**************@TK2MSFTNGP11.phx.gbl:
Lay it on me brother :-) As a side note, was not talking about Indy, but


Yes. I know - its just that I know all about this threading stuff and common
misconceptions because of having to explain it so many times on the Delphi
forums. :)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #15
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:u6**************@tk2msftngp13.phx.gbl:
A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
The problem with this is there is a limit of 64 per call, so you still need
to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.
contention for shared resources goes up with number of threads.. If many
clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of
this from managed code however.


Indy has support for this using fibers. This part is in SuperCore and hasnt
been ported to .net yet. This part will likely have to be unmanaged until
fibers, etc are accesible as managed objects.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #16
"Steve - DND" <steve!@!digitalnothing.com> wrote in
news:ux**************@TK2MSFTNGP09.phx.gbl:
One thing I have a question on is scalability performance. I keep
reading that a multi-threaded approach may not necessarily scale very
Key word is "may not". In most cases, espeically with sockets its fine. In
fact its better.
well. How many threads is too many before the switching starts to kill
the app? I will probably have about 50-75(possibly up to 100) concurrent
It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet. :)

What you will hit before any limits is the process memory limit. You will hit
this at about 1000 threads (There are ways to go higher, but normally you
should not as 1000 threads in one process has other issues).

If you arent going over 200-300 threads, dont even worry about it. That is
unless each one is calculating Pi to the 4 billionth digit.
connections at peak times. From what I have read, it sounds like this
would be too many threads to create.


Not at all. Windows wont even notice that many.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #17
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:eK**************@TK2MSFTNGP09.phx.gbl:
I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller
Not true as people assume.... If they are all active calculating Pi - yes.
But active in this case means "socket activity" then no. The reason for
this is bandwidth.

Lets take a 100 MB ethernet. Calculate its max speed against the CPU. You
will see that it is MANY magnitudes slower than even todays most slothful
of CPUs. Factor in hardward buffers, and software driver buffers and each
thread is activated very rarely in the scheme of things even in a fully
loaded ethernet card.

Beause of this, threads spend most of their time waiting on network calls.
This causes them to be skipped over by the scheduler until their blocking
calls have returned. This reduces the "theoretical" context switching by
many thousands.
quantum time to do work as more threads are running in the system. So
Most thread in this type of system wont reach their quantum because they
will voluntarily sleep first.
less time each thread has to work, more context switch time, more
Nope - because they will switch to threads which are running, which in such
a system most threads on each pass will be sleeping. In fact many of the
switches will be to the idle or system threads.
contention for locks, etc. I am not sure the Async read and writes
using standard Socket or TCPClient are much better. AFAICT, if you post
There are two types of asyncs. The asyncs with windows messages are usually
even slower.

Another factor is the blocking "thunk" to kernel level. But again, only for
advanced systems.

In the scheme of things, what this user describes is a very small system
and he should focus on clean readable code. Performance will be just fine
and there is not need to build and advanced design and muck up his code.
If perf is key, you may have to resort to overlapped io sockets or
WSAEventSelect and wrap a few pInvoke apis.


Problems there too. :)

IOCP is the only TRUE fast way, and it has a TON of problems that should be
avoided and only used as a LAST resort.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #18
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:
It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet. :)


This metric is fairly meaningless because it doesn't indicate how many
of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.

If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.
Nov 15 '05 #19
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:
It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet. :)


This metric is fairly meaningless because it doesn't indicate how many
of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.

If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.
Nov 15 '05 #20
William Stacey [MVP] <st***********@mvps.org> wrote:
A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
event and look that up to get your client socket object. You need to use
the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this
in managed code.


I believe WaitForMultipleEvents() can only wait on 64 event objects at
a time. The OP mentioned a potential peak as high as 100, so if he
used this approach, a modified version would be required. Also I
believe WaitForMultipleObjects() tends to favor the lower numbered
objects which could present problems for certain usage patterns.
Nov 15 '05 #21
William Stacey [MVP] <st***********@mvps.org> wrote:
A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
event and look that up to get your client socket object. You need to use
the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this
in managed code.


I believe WaitForMultipleEvents() can only wait on 64 event objects at
a time. The OP mentioned a potential peak as high as 100, so if he
used this approach, a modified version would be required. Also I
believe WaitForMultipleObjects() tends to favor the lower numbered
objects which could present problems for certain usage patterns.
Nov 15 '05 #22
be****@dogs-like-spam.com wrote in
news:40*********************@newsreader.visi.com:
This metric is fairly meaningless because it doesn't indicate how many
Its not meaningless. It wasnt meant to point out that they all could be
active. But nearly all users are under the impression that if you even CREATE
100 threads you will see smoke rolling. This proves this point false.
of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.
As to the second part - you need to read the rest of the message. I have
built servers up to 1,000 thread that run just fine and do not consume tons
or RAM, nor CPU.

In stress testing I've pushed them above 1,500.
If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.


Wrong - Please go back and read my complete message. It appear you just read
the first part.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #23
be****@dogs-like-spam.com wrote in
news:40*********************@newsreader.visi.com:
This metric is fairly meaningless because it doesn't indicate how many
Its not meaningless. It wasnt meant to point out that they all could be
active. But nearly all users are under the impression that if you even CREATE
100 threads you will see smoke rolling. This proves this point false.
of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.
As to the second part - you need to read the rest of the message. I have
built servers up to 1,000 thread that run just fine and do not consume tons
or RAM, nor CPU.

In stress testing I've pushed them above 1,500.
If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.


Wrong - Please go back and read my complete message. It appear you just read
the first part.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #24
Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA

--
William Stacey, MVP

<be****@dogs-like-spam.com> wrote in message
news:40*********************@newsreader.visi.com.. .
William Stacey [MVP] <st***********@mvps.org> wrote:
A good way to go would be to wait on multiple socket events (one socket for each tcp client) in a WaitForMultipleEvents call, then get the index of the event and look that up to get your client socket object. You need to use the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this in managed code.


I believe WaitForMultipleEvents() can only wait on 64 event objects at
a time. The OP mentioned a potential peak as high as 100, so if he
used this approach, a modified version would be required. Also I
believe WaitForMultipleObjects() tends to favor the lower numbered
objects which could present problems for certain usage patterns.

Nov 15 '05 #25
Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA

--
William Stacey, MVP

<be****@dogs-like-spam.com> wrote in message
news:40*********************@newsreader.visi.com.. .
William Stacey [MVP] <st***********@mvps.org> wrote:
A good way to go would be to wait on multiple socket events (one socket for each tcp client) in a WaitForMultipleEvents call, then get the index of the event and look that up to get your client socket object. You need to use the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this in managed code.


I believe WaitForMultipleEvents() can only wait on 64 event objects at
a time. The OP mentioned a potential peak as high as 100, so if he
used this approach, a modified version would be required. Also I
believe WaitForMultipleObjects() tends to favor the lower numbered
objects which could present problems for certain usage patterns.

Nov 15 '05 #26
"William Stacey [MVP]" <st***********@mvps.org> wrote in news:#qTbXII#DHA.220
@TK2MSFTNGP09.phx.gbl:
Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA


Not unless you log it somewhere..
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #27
"William Stacey [MVP]" <st***********@mvps.org> wrote in news:#qTbXII#DHA.220
@TK2MSFTNGP09.phx.gbl:
Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA


Not unless you log it somewhere..
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #28
That is kinda the issue however. All you know is that the event was
signaled - you don't know what socket caused the signal (afaict). So I
guess you can wait on the event and enum the active socket list to poll each
one to see if it has some data and then wait on event again in a loop.

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in news:#qTbXII#DHA.220 @TK2MSFTNGP09.phx.gbl:
Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event to fire? TIA


Not unless you log it somewhere..
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Nov 15 '05 #29
I gotta tell ya Chad, you made me see a new light on this. I went and put
together a virtual socket class that "creates" packets for reading and
created two tests. First test is creating X number of threads and one
socket per thread that reads N number of packets. Second test was creating
same number of sockets in a object that manages the sockets in a collection
and posts an event that a worker thread(s) waits on. Results vary based on
syncing threads with a shared object (i.e. a fake write queue for example)
that you can set to sleep and/or spinWait. I could get ~20,000 threads
running pretty well. Trying to start 30,000 locked up my app each time, but
could just stop it in TaskManager without a crash. I never saw TaskManager
Threads go over ~571, so not sure if that is just showing running threads or
if CLR only releases so many OS threads and does some other management in
the background. Very suprising results. It's not a clear winner in all
cases and not sure of effects of running 1000+ threads for long time in a
server app, but these results are interesting. If anyone wants to play with
this test harness, I can post it to web. It fun to play with different
options to see time effects of injecting sleeps or waits, etc. Cheers!

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:u6**************@tk2msftngp13.phx.gbl:
A good way to go would be to wait on multiple socket events (one socket for each tcp client) in a WaitForMultipleEvents call, then get the index of the

The problem with this is there is a limit of 64 per call, so you still need to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.
contention for shared resources goes up with number of threads.. If
many clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of this from managed code however.


Indy has support for this using fibers. This part is in SuperCore and

hasnt been ported to .net yet. This part will likely have to be unmanaged until
fibers, etc are accesible as managed objects.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Nov 15 '05 #30
Hmm, I would like to see some code.
With a default 1MB stack space reserved per thread and a 2GB user address
space, the max number of threads is less than 2000, you can't have 20000
threads created.
You said:
<I could get ~20,000 threads running pretty well. >
But taskmanager only showed ~571, that means currently only that number of
OS threads where created. And from here the system started trashing, right.
Creating additional threads takes so much time that you won't get any
additional threads from the OS.

Willy.

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Os****************@TK2MSFTNGP12.phx.gbl...
I gotta tell ya Chad, you made me see a new light on this. I went and put
together a virtual socket class that "creates" packets for reading and
created two tests. First test is creating X number of threads and one
socket per thread that reads N number of packets. Second test was
creating
same number of sockets in a object that manages the sockets in a
collection
and posts an event that a worker thread(s) waits on. Results vary based
on
syncing threads with a shared object (i.e. a fake write queue for example)
that you can set to sleep and/or spinWait. I could get ~20,000 threads
running pretty well. Trying to start 30,000 locked up my app each time,
but
could just stop it in TaskManager without a crash. I never saw
TaskManager
Threads go over ~571, so not sure if that is just showing running threads
or
if CLR only releases so many OS threads and does some other management in
the background. Very suprising results. It's not a clear winner in all
cases and not sure of effects of running 1000+ threads for long time in a
server app, but these results are interesting. If anyone wants to play
with
this test harness, I can post it to web. It fun to play with different
options to see time effects of injecting sleeps or waits, etc. Cheers!

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:u6**************@tk2msftngp13.phx.gbl:
> A good way to go would be to wait on multiple socket events (one socket for > each tcp client) in a WaitForMultipleEvents call, then get the index of the

The problem with this is there is a limit of 64 per call, so you still

need
to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.
> contention for shared resources goes up with number of threads.. If

many > clients, you probably want to go async. You could probably also use
> I/O
> completion ports and a thread pool, have not really seen good examples of > this from managed code however.


Indy has support for this using fibers. This part is in SuperCore and

hasnt
been ported to .net yet. This part will likely have to be unmanaged until
fibers, etc are accesible as managed objects.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


Nov 15 '05 #31
Sounds strange, but it worked. .Net must be using fibers or something.
I'll post the code.

--
William Stacey, MVP

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uK**************@TK2MSFTNGP09.phx.gbl...
Hmm, I would like to see some code.
With a default 1MB stack space reserved per thread and a 2GB user address
space, the max number of threads is less than 2000, you can't have 20000
threads created.
You said:
<I could get ~20,000 threads running pretty well. >
But taskmanager only showed ~571, that means currently only that number of
OS threads where created. And from here the system started trashing, right. Creating additional threads takes so much time that you won't get any
additional threads from the OS.

Willy.

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Os****************@TK2MSFTNGP12.phx.gbl...
I gotta tell ya Chad, you made me see a new light on this. I went and put together a virtual socket class that "creates" packets for reading and
created two tests. First test is creating X number of threads and one
socket per thread that reads N number of packets. Second test was
creating
same number of sockets in a object that manages the sockets in a
collection
and posts an event that a worker thread(s) waits on. Results vary based
on
syncing threads with a shared object (i.e. a fake write queue for example) that you can set to sleep and/or spinWait. I could get ~20,000 threads
running pretty well. Trying to start 30,000 locked up my app each time,
but
could just stop it in TaskManager without a crash. I never saw
TaskManager
Threads go over ~571, so not sure if that is just showing running threads or
if CLR only releases so many OS threads and does some other management in the background. Very suprising results. It's not a clear winner in all
cases and not sure of effects of running 1000+ threads for long time in a server app, but these results are interesting. If anyone wants to play
with
this test harness, I can post it to web. It fun to play with different
options to see time effects of injecting sleeps or waits, etc. Cheers!

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:u6**************@tk2msftngp13.phx.gbl:
> A good way to go would be to wait on multiple socket events (one socket
for
> each tcp client) in a WaitForMultipleEvents call, then get the index
of the

The problem with this is there is a limit of 64 per call, so you still

need
to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.

> contention for shared resources goes up with number of threads.. If

many
> clients, you probably want to go async. You could probably also use
> I/O
> completion ports and a thread pool, have not really seen good
examples of
> this from managed code however.

Indy has support for this using fibers. This part is in SuperCore and

hasnt
been ported to .net yet. This part will likely have to be unmanaged

until fibers, etc are accesible as managed objects.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"




Nov 15 '05 #32
No it doesn't use fibers. The problem is that the number of threads
currently created (what you see in perfmon), set's such a load on the system
(CPU and Page File IO) that new threads aren't getting created.
Please watch some perf counters like Process Threads ,Process Virtual Memory
size and Page File size and you will understand why.

Willy.
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...
Sounds strange, but it worked. .Net must be using fibers or something.
I'll post the code.

--
William Stacey, MVP

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uK**************@TK2MSFTNGP09.phx.gbl...
Hmm, I would like to see some code.
With a default 1MB stack space reserved per thread and a 2GB user address
space, the max number of threads is less than 2000, you can't have 20000
threads created.
You said:
<I could get ~20,000 threads running pretty well. >
But taskmanager only showed ~571, that means currently only that number
of
OS threads where created. And from here the system started trashing,

right.
Creating additional threads takes so much time that you won't get any
additional threads from the OS.

Willy.

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Os****************@TK2MSFTNGP12.phx.gbl...
>I gotta tell ya Chad, you made me see a new light on this. I went and put > together a virtual socket class that "creates" packets for reading and
> created two tests. First test is creating X number of threads and one
> socket per thread that reads N number of packets. Second test was
> creating
> same number of sockets in a object that manages the sockets in a
> collection
> and posts an event that a worker thread(s) waits on. Results vary
> based
> on
> syncing threads with a shared object (i.e. a fake write queue for example) > that you can set to sleep and/or spinWait. I could get ~20,000 threads
> running pretty well. Trying to start 30,000 locked up my app each
> time,
> but
> could just stop it in TaskManager without a crash. I never saw
> TaskManager
> Threads go over ~571, so not sure if that is just showing running threads > or
> if CLR only releases so many OS threads and does some other management in > the background. Very suprising results. It's not a clear winner in
> all
> cases and not sure of effects of running 1000+ threads for long time in a > server app, but these results are interesting. If anyone wants to play
> with
> this test harness, I can post it to web. It fun to play with different
> options to see time effects of injecting sleeps or waits, etc. Cheers!
>
> --
> William Stacey, MVP
>
> "Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
> news:Xn******************@127.0.0.1...
>> "William Stacey [MVP]" <st***********@mvps.org> wrote in
>> news:u6**************@tk2msftngp13.phx.gbl:
>> > A good way to go would be to wait on multiple socket events (one socket > for
>> > each tcp client) in a WaitForMultipleEvents call, then get the index of > the
>>
>> The problem with this is there is a limit of 64 per call, so you still
> need
>> to break it into threads anways. And then you break your code away
>> from
>> seqeuntial to handling 64 state machines... makes for ugly code.
>>
>> > contention for shared resources goes up with number of threads.. If
> many
>> > clients, you probably want to go async. You could probably also use
>> > I/O
>> > completion ports and a thread pool, have not really seen good examples > of
>> > this from managed code however.
>>
>> Indy has support for this using fibers. This part is in SuperCore and
> hasnt
>> been ported to .net yet. This part will likely have to be unmanaged until >> fibers, etc are accesible as managed objects.
>>
>>
>> --
>> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>> "Programming is an art form that fights back"
>
>


Nov 15 '05 #33
Your right Willy. I botched it after looking harder. I created the 20,000,
then started them one after another in a loop. The first ones started and
finished before the next couple couple started and chased each other like
that until loop done - so probably no more then 10-30 actually ran at same
time. I fixed that and could get about 1700 but never 1800 started at same
time. I will fix some more to get some better results. Actually, I am glad
of this because this goes more inline with what I though would happen before
I started the test and what I have read in many good books on the subject
(so I don't have to burn them now.) Will post the code anyway when I
tighten a few things up and post some numbers. As ~1700 seems to be max
(without hardly anything else going on), I would venture a guess that
100-500 may be ~workable in a running server for a thread per client
approach (not sure as this point). That means (I think) a socket collection
with an Event at the head of a loop is the ~only way to do high connection
(500+) count TCP servers. BTW - How does IIS work it?

Thanks for post. Cheers!

--
William Stacey, MVP

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uj**************@TK2MSFTNGP10.phx.gbl...
No it doesn't use fibers. The problem is that the number of threads
currently created (what you see in perfmon), set's such a load on the system (CPU and Page File IO) that new threads aren't getting created.
Please watch some perf counters like Process Threads ,Process Virtual Memory size and Page File size and you will understand why.

Willy.
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...
Sounds strange, but it worked. .Net must be using fibers or something.
I'll post the code.

--
William Stacey, MVP

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:uK**************@TK2MSFTNGP09.phx.gbl...
Hmm, I would like to see some code.
With a default 1MB stack space reserved per thread and a 2GB user address space, the max number of threads is less than 2000, you can't have 20000 threads created.
You said:
<I could get ~20,000 threads running pretty well. >
But taskmanager only showed ~571, that means currently only that number
of
OS threads where created. And from here the system started trashing,

right.
Creating additional threads takes so much time that you won't get any
additional threads from the OS.

Willy.

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Os****************@TK2MSFTNGP12.phx.gbl...
>I gotta tell ya Chad, you made me see a new light on this. I went and

put
> together a virtual socket class that "creates" packets for reading and > created two tests. First test is creating X number of threads and one > socket per thread that reads N number of packets. Second test was
> creating
> same number of sockets in a object that manages the sockets in a
> collection
> and posts an event that a worker thread(s) waits on. Results vary
> based
> on
> syncing threads with a shared object (i.e. a fake write queue for

example)
> that you can set to sleep and/or spinWait. I could get ~20,000 threads > running pretty well. Trying to start 30,000 locked up my app each
> time,
> but
> could just stop it in TaskManager without a crash. I never saw
> TaskManager
> Threads go over ~571, so not sure if that is just showing running

threads
> or
> if CLR only releases so many OS threads and does some other management
in
> the background. Very suprising results. It's not a clear winner in
> all
> cases and not sure of effects of running 1000+ threads for long time
in a
> server app, but these results are interesting. If anyone wants to
play > with
> this test harness, I can post it to web. It fun to play with different > options to see time effects of injecting sleeps or waits, etc. Cheers! >
> --
> William Stacey, MVP
>
> "Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
> news:Xn******************@127.0.0.1...
>> "William Stacey [MVP]" <st***********@mvps.org> wrote in
>> news:u6**************@tk2msftngp13.phx.gbl:
>> > A good way to go would be to wait on multiple socket events (one

socket
> for
>> > each tcp client) in a WaitForMultipleEvents call, then get the index of
> the
>>
>> The problem with this is there is a limit of 64 per call, so you

still > need
>> to break it into threads anways. And then you break your code away
>> from
>> seqeuntial to handling 64 state machines... makes for ugly code.
>>
>> > contention for shared resources goes up with number of threads.. If > many
>> > clients, you probably want to go async. You could probably also use >> > I/O
>> > completion ports and a thread pool, have not really seen good

examples
> of
>> > this from managed code however.
>>
>> Indy has support for this using fibers. This part is in SuperCore and > hasnt
>> been ported to .net yet. This part will likely have to be unmanaged

until
>> fibers, etc are accesible as managed objects.
>>
>>
>> --
>> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
>> "Programming is an art form that fights back"
>
>



Nov 15 '05 #34
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:#u**************@TK2MSFTNGP11.phx.gbl:
up and post some numbers. As ~1700 seems to be max (without hardly
Yes it is becuase of process limits. Each thread is allocated 2M of process
space, and in a 32 bit space 4G is the limit. So thats 2000, but a process
already has allocated space... so 1700 is about right.

In XP you can create threads with smaller process spaces to bump it higher.
Im not sure if .net threads have this option.
anything else going on), I would venture a guess that 100-500 may be
~workable in a running server for a thread per client approach (not sure
100-500 is very workable. I have servers running 24/7/365 with that many
threads in many many installations wtih no issues and no major CPU drain.

Even 1,000 is feasible if you dont build in your own bottlenecks. In most
cases interthread communication or contention in user code is the
bottleneck long before the threads are.
as this point). That means (I think) a socket collection with an Event
at the head of a loop is the ~only way to do high connection (500+)
Nope.... As I said even 1000 is ok. And I've gone as high as 1500
successfully.
count TCP servers. BTW - How does IIS work it?


IIS uses IOCP and thread pools. Remember IIS is HTTP and HTTP is "hit and
go" so it doesnt need to keep thread around for "spurious" connections.

Indy 10 has an option to use fibers and IOCP. The cool thing is its all
hidden from the user and they can switch from threads + winsock to fibers +
IOCP without changing a single line of their code.

And since Indy 10 has its own scheduler built in - its VERY efficient. Its
not been optimized yet but its been through some serious testing and will
push to 10,000+ and likely when done push to 40,000 or more (the socket
limit of Windows) on a machine with enough RAM to allocate sockets. So in
Indy 10 - the limit now is Windows and how many sockets it can allocate,
not the threads.

The problem at 40,000 again becomes one of just sheer memory though... 64
bit will help here.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #35
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:Os**************@TK2MSFTNGP12.phx.gbl:
I gotta tell ya Chad, you made me see a new light on this. I went and


Good. :)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #36
> Nope.... As I said even 1000 is ok. And I've gone as high as 1500
successfully.
Well I was thinking more in terms of being safe and not pushing things util
it crashes as we may not have perfect knowledge upfront of all the mem
issues and async delegates and other IO (disk, etc). If 1700 is around max,
then I would not feel real sure about pushing 1000 as that gets close, and
you may have other async stuff going on and the rest of mem and allocations
your program is doing. Not to mention other network programs the server
could be running - assuming we don't have 100% rule over the box for one
program. If you had to pick some number, it would probably be less then
1000 with some rounded down fudge factor for safety. That said, you end up
having to pick a max number and error on the safe side. So if you settle on
700, but you need 1000-10,0000+ max connections, the socket collection with
event is the only .net/win32 way I see at this point without going to IOCPs.
(not assuming Indy for sake of discussion.)
And since Indy 10 has its own scheduler built in - its VERY efficient. Its
not been optimized yet but its been through some serious testing and will
push to 10,000+ and likely when done push to 40,000 or more (the socket
limit of Windows) on a machine with enough RAM to allocate sockets. So in
Indy 10 - the limit now is Windows and how many sockets it can allocate,
not the threads.


Cool. Thanks Chad.

--wjs

Nov 15 '05 #37

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:#u**************@TK2MSFTNGP11.phx.gbl:
up and post some numbers. As ~1700 seems to be max (without hardly


Yes it is becuase of process limits. Each thread is allocated 2M of
process
space, and in a 32 bit space 4G is the limit. So thats 2000, but a process
already has allocated space... so 1700 is about right.


User space is 2GB (half of the 4GB process space) or 3GB on
"LargeAddressAware" enabled systems (3GB switch), default stack space is 1MB
per OS thread, .NET doesn't expose a managed way to create threads with less
stack space, running XP and higher, one can allways call CreateThread using
PInvoke.
The default Stackspace can be changed using EDITBIN.EXE.

Willy.

Nov 15 '05 #38
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in
news:Os**************@TK2MSFTNGP10.phx.gbl:
User space is 2GB (half of the 4GB process space) or 3GB on
"LargeAddressAware" enabled systems (3GB switch), default stack space is
Aah yes. Sorry you are right on the 1M and 2G. Was late last night. ;)
1MB per OS thread, .NET doesn't expose a managed way to create threads
This is a shame. :(
The default Stackspace can be changed using EDITBIN.EXE.


EditBin? You mean as in editing the .net framework?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #39
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:
The default Stackspace can be changed using EDITBIN.EXE.


EditBin? You mean as in editing the .net framework?


No - editing the assembly, which is still just a PE file after all. I
believe it can be done, but it's not recommended :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #40
Inline ***

Willy.

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in
news:Os**************@TK2MSFTNGP10.phx.gbl:
User space is 2GB (half of the 4GB process space) or 3GB on
"LargeAddressAware" enabled systems (3GB switch), default stack space is
Aah yes. Sorry you are right on the 1M and 2G. Was late last night. ;)
1MB per OS thread, .NET doesn't expose a managed way to create threads


This is a shame. :(

*** Not realy, except for special cases where you know exactly how much
stack space will be required, but here I assume you will write your own CLR
host, just like asp.net does.
The default Stackspace can be changed using EDITBIN.EXE.


EditBin? You mean as in editing the .net framework?


*** No, the executable assembly, which is just a normal PE file.
So, editbin /stack:256000 YourAssembly.exe will set the default reserved
stack size to 256Kb.
Now the problem here is that all threads will take the same value, a low
value may lead to stackoverflow exceptions being thrown, when set too high
its just a waste of virtual memory. So IMO it's better to leave the value at
1MB default.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Nov 15 '05 #41
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:#S**************@TK2MSFTNGP10.phx.gbl:
Well I was thinking more in terms of being safe and not pushing things
util it crashes as we may not have perfect knowledge upfront of all the
mem issues and async delegates and other IO (disk, etc). If 1700 is
around max, then I would not feel real sure about pushing 1000 as that
gets close, and you may have other async stuff going on and the rest of


1000 is not close to 1700. :)

When my son is 10 - I wont be worried about him "almost" being 17. :)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #42
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in
news:ue**************@tk2msftngp13.phx.gbl:
*** No, the executable assembly, which is just a normal PE file.
So, editbin /stack:256000 YourAssembly.exe will set the default
reserved stack size to 256Kb.
Aah by setting the process one. Thats how its done pre XP too.
Now the problem here is that all threads will take the same value, a low
value may lead to stackoverflow exceptions being thrown, when set too
high its just a waste of virtual memory. So IMO it's better to leave the
value at 1MB default.


In XP you can set it per thread - and it works very nicely.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #43
inline ***
Willy.

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in
news:ue**************@tk2msftngp13.phx.gbl:
*** No, the executable assembly, which is just a normal PE file.
So, editbin /stack:256000 YourAssembly.exe will set the default
reserved stack size to 256Kb.
Aah by setting the process one. Thats how its done pre XP too.

*** Yep.
Now the problem here is that all threads will take the same value, a low
value may lead to stackoverflow exceptions being thrown, when set too
high its just a waste of virtual memory. So IMO it's better to leave the
value at 1MB default.


In XP you can set it per thread - and it works very nicely.

*** Sure, but not from within .NET, unless you PInvoke or use MC++.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Nov 15 '05 #44
Ok wise guy. Then lets play "pick a number" then. What's your number?
Factor in some working space for your actual program data, etc. And factor
in some fudge factor so as not to always be bumping max. Seems when you
push the memory line, strange things seem to happen. So its not 1700 or
1699, or even 1698. However it is probably > 700 and less then 1700.

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
"William Stacey [MVP]" <st***********@mvps.org> wrote in
news:#S**************@TK2MSFTNGP10.phx.gbl:
Well I was thinking more in terms of being safe and not pushing things
util it crashes as we may not have perfect knowledge upfront of all the
mem issues and async delegates and other IO (disk, etc). If 1700 is
around max, then I would not feel real sure about pushing 1000 as that
gets close, and you may have other async stuff going on and the rest of


1000 is not close to 1700. :)

When my son is 10 - I wont be worried about him "almost" being 17. :)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


Nov 15 '05 #45
Chad,
Indy 10 has an option to use fibers and IOCP. The cool thing is its all
hidden from the user and they can switch from threads + winsock to fibers +
IOCP without changing a single line of their code.

Are you still writing Delphi code or have you switched to C#?

Is Indy 10 written in C# or still in Delphi?

Dave
Nov 15 '05 #46
"William Stacey [MVP]" <st***********@mvps.org> wrote in news:O7agEJ#
$D*******@TK2MSFTNGP10.phx.gbl:
Ok wise guy. Then lets play "pick a number" then. What's your number?
Factor in some working space for your actual program data, etc. And factor
in some fudge factor so as not to always be bumping max. Seems when you
push the memory line, strange things seem to happen. So its not 1700 or
1699, or even 1698. However it is probably > 700 and less then 1700.


1699 and so on yes - but you stated 1000 was almost 1700. Thats what I was
replying to.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #47
D. Yates <fo****@hotmail.com> wrote in
news:a9********************************@4ax.com:
Are you still writing Delphi code or have you switched to C#?
Still Delphi. We use C# in our company for demos and some VS specific code,
otherwise still all Delphi. Only Delphi allows us with one source code base
to support Win32, .Net and Linux.
Is Indy 10 written in C# or still in Delphi?


Delphi. I think you underestimate the sheer size and volume of code in Indy
if you think it could be ported to C# so easily. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #48
"William Stacey [MVP]" <st***********@mvps.org> wrote in news:O7agEJ#
$D*******@TK2MSFTNGP10.phx.gbl:
Ok wise guy. Then lets play "pick a number" then. What's your number?
Factor in some working space for your actual program data, etc. And factor
in some fudge factor so as not to always be bumping max. Seems when you


Here is the quote BTW:
"If 1700 is around max, then I would not feel real sure about pushing 1000 as
that gets close,"

I dont dispute that 1000 may be too much in most situations - I simply
disputed this statement that 1000 is close to 17000.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Nov 15 '05 #49

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: ... | last post by:
Does anyone know a good tutorial on asynchronous programming in .net AsyncCallback And IASyncResult are driving me crazy. And the msdn documentation is not really helpful on this topic I...
4
by: Chris | last post by:
Hello, With asynchronous programming : Why does the callback-function (running in a worker thread) may not update the state of a control on the main-form ? The docs say that you must use a...
9
by: Michael Lindsey | last post by:
I need to write a server app to send images to client GUIs that are outside of the server's domain. The client will have the file system path to the image but can not access the file system. I am...
4
by: bernardpace | last post by:
Hi, I am trying to get more familiar with asynchronous programming. I was reading through the document found on the page: ...
1
by: Julian Hershel | last post by:
Reading about asynchronous programming (ms-help://MS.NETFrameworkSDK/cpguidenf/html/cpconasynchronousdesignpatterno verview.htm) I could not clarify some doubts. Hope you can help me. 1) Are...
1
by: org | last post by:
Hi, I'm developing a web service with should be used by an .NET CF2 client and an .NET 2.0 Windows client. I've tried to put all the connection logic into one class, which could be used in...
5
by: Ryan Liu | last post by:
Hi, I read Microsoft SDK, ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpovrasynchronousprogramming overview.htm there are 4 ways to call EndInvoke: The code in this topic demonstrates...
3
by: =?Utf-8?B?bWs=?= | last post by:
Hi everyone, I need to refactor some of our processes using the asynchronous programming model. I have defined a couple of arrays of delegates to pipline the asynchronous invocations through...
3
by: senfo | last post by:
I recently read an MSDN article by Jeff Prosise titled, Scalable Apps with Asynchronous Programming in ASP.NET (http://msdn.microsoft.com/msdnmag/issues/07/03/WickedCode/). In the article, Jeff...
2
by: =?Utf-8?B?U3JpcmFtIE1hbGxhanlvc3VsYQ==?= | last post by:
Hi, I was going through the article (http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/) regarding async programming in ASP.Net 2.0 but did not find much of an use with it. Actually...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.