Graeme wrote 9 lines
-- Jason Now --
Hi Graeme! I always enjoy your posts.
I seriously am not cycling the threads like your comment suggests. I actually have proof that the threads are working EQUALLY well in Linux and Win32... BUT this DOESN'T mean they are 100% - because like I was trying to stress... I took that little demo with two simultaneous threads looping, expanded on the "working" model. I can have any number of threads running simultaneously no problem -
what I did was make it so - each of my threads "Execute" method - looks sort of like:
procedure mythreadclass.execute
begin
repeat
CallSomeCodeHere;
self.bIdle:=true;
self.suspend;
until terminated;
end;So I Create a pool of them, set the idle flags to false... why? Just so I KNOW the thread finished the loop and is ready for another go around as I call it.
(Geeesh... these self taught guys (like myself) don't even know the nomemclature.. I don't know a semaphore from a mutex for example - but I've dabbled with my own 32 bit OS's with task switching... fun but to much for one person - go figure)
So, My Main program is actually a multiplexor - but its concentrating on a little "Windowed" console app - like Free Vision - except mine is homemade from the console, crt, mouse, keyboard units on up. (Mouse doesn't work in my Linux.. but I digress.. prob a gpm thing )
Anyways - as its scanning for user IO at the "server", it has a millisecond timer thing, that basically says every X milliseconds, see if there are any new arrivals - (jobs to do) - and then it grabs info about all the new arrivals until processed, in this order....
1: Look for those IDLE threads in the thread pool, Got One? Cool, (Its still suspended)
2: load up the variables in the thread pertaining to the JOB - basically initialize it with all the info it needs to perform a cycle....
3: "RESUME IT"... Good Bye thread - its off and running. I don't even THINK about it again until its idle again... (well, the main program doesn't even consider it - I should say - until its self.bIdle=TRUE) so I'm not doing all this thread micro-management that your comment seemed to suggest, and was a response to.
4.... meanwhile main program finishing "launching" work tasks, and when done, goes back to UI stuff, and what ever. This all happens very smoothly and I don't think I'll need to change this architecture until my web applications are getting nailed like 50 requests a second or something - where WORK TO DO makes the SERVER UI to unresponsive under load. Either way
- I just change the LOOP that tries to tackle all pending work at once - to a controlled number, and grab more stuff each go round...
Behind the scenes - the threads are purring away - I have a couple "SLEEPS" here and there - but only when it seems appropriate - like the "THREAD is waiting on something..." ... on in the main program - ... but these are not related to each other - just my program trying to give up the CPU when its, (in one program I have a flag literally named) "bTrulyIdle". Truly Idle menas - I looked around - there's nothing to do.... so it "Sleeps" (Actually in my prog - if win 32 I call win32 API - and in linux I use sysutils sleep, so I have a function called "Yield" that wraps this up rather nicely .. I have reasons - I TRY to not use sysutils in ONE app due to EXE size reasons
- but in linux I just deal - cuz I need the SLEEP function - in all my other apps SIZE is not a factor - straight up speed is - (Free Pascal seems GREAT to me in this arena....)
Jason P Sage