Automatic WSAEVENT thread pooling, handles thousands of 'em...

[SenderX]

You ever get pissed when you can't wait on more than 64 handles at a time?

You ever get mad when you try to code a thread scheme, that can bypass the
64 handle limit?

You ever get sick of trying to manage all those threads, and arrays when
using WSAEVENT's and WaitForMultiAPI?

Fear no more!

=)

I have posted about 75% of my Thread Pool API on my site, and the parts that
are there will handle all of the above.

http://AppCore.home.attbi.com/src/ThreadPool.c

http://AppCore.home.attbi.com/include/ThreadPool.h

http://AppCore.home.attbi.com/include/sys/sysThreadPool.h

My site has working test code that posts thousands of semaphores, and cycles
them in the thread pool.

It does all of the following...

1. Automatically dispatches HANDLES to the correct amount of threads.

2. Dispatches HANDLES to front line threads first, to keep the pool down.

3. Its a dynamic pool, threads only stay around if they have to.

4. Handles HANDLE timeouts in a fair manner.

5. Auto-balances itself against your parameters.

6. Auto-Throttles overflowing posts, by returning them to you as cancelled,
where they can be tried again.

7. The pool can send each post to its own callback function.

8. Producer threads can pipeline HANDLES to the pool in a super fast manner,
using my Queue API.

9. Keeps track of all pending operations.

Remember this is only 75% complete. When I finish tweaking it some more, I
will post my full API...

The full Thread Pool API will be the actual base for my Socket Peer API.

Oh, Dave G.

You can use this to implement a scaleable ConnectEx emulation using
WSAConnect, that will work on Win98 up to Server 2003 and beyond...

My Socket Peer API does this, and it works great. It can handle thousands of
pending connections with it.

Please comment on it...

;)

--
The designer of the SMP and HyperThread friendly, AppCore library.

http://AppCore.home.attbi.com

[Skybuck Flying]

So when will you write a udp speed test to show off it's performance ? :D

[SenderX]

> So when will you write a udp speed test to show off it's performance ? :D

Actually...

I am going to have a UDP file transfer system for Socket Peer API's to use.

I have already explained this algo in a previous post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=MTvH9.23
0033%24NH2.15577%40sccrnsc01&rnum=5&prev=/groups%3Fq%3D%2BUDP%2Bgroup:alt.wi
nsock.programming%2Bauthor:SenderX%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF
-8%26selm%3DMTvH9.230033%2524NH2.15577%2540sccrnsc01%26rnum%3D5

Read my posts in the thread.

The UDP data session, has to mixed with a TCP control session. This gives us
reliability over UDP with minimal work...

The TCP control session is in direct control of UDP data sessions.

You can use a single TCP control session to manage concurrent file
transfers.

The rough protocol would be as follows:

1. Starting a session

A client would connect to the server via. TCP.

2. Client file request

The client would send a request via. TCP.

The server would get the request, and send a response saying that UDP
packets are coming.

3. Server sending file

The server would follow the response, with UDP packets containg file data
and its offset into the file.

The server would blast the whole file there.

The server would send a request to the client asking it if it got
everything...

If the client hasn't received the entire file by the time it got the ( you
got everything ) request from the server. It sends a request asking for the
file offsets it did not get, and loops back to the start of # 3.

Your using UDP for data transfer, and TCP as a controller.

This should be faster than TCP for transferring large files...

What do you think?

[Skybuck Flying]

What I am interested in when it comes to performance is three things:

1. how fast can it send udp packets
2. how fast can it receive udp packets
3. how much cpu does it use.

So having a test program for your code would be nice :)

[Skybuck Flying]

I just had an idea how to reduce cpu usage.

My thread is always running.

So making the thread block it's own execution will reduce cpu usage.

Ofcourse using sleep won't cut it... because it sleeps to much.

Windows NT has a new thing... waitable timers... with 100 nanosecond
accuracy.

So a thread could use a waitable timer and then call wait for single object
or something.

Then it gets signalled and proceeds with executing.

So this mechanism could serve as a speed throttle for the thread :)

The cool thing is that this way the interval between loops will be the
same...

So the execution is nicely spread over time.

I don't know how to do it for windows 98 at this point :)

Anyway.. if it works it would be awesome ! :)

It's a general way that can be used for any application.

But currently I have no time to program/test it out :)

I did code another way though...

I tell the thread to do an ammount of work... and when it is done it
suspends itself.

But this does not have the desired property of spreading the work across
time :)

[SenderX]

> So a thread could use a waitable timer and then call wait for single
object
> or something.

WaitForAPI's will behave like Sleep, when the handle(s) they wait on are not
signaled.