Jason P Sage wrote: > I was trying to avoid sysutils sleep(0) in linux platform due to the size of > sysutils. The fact I don't know how to make dynamic linking work on linux > yet - (use shared libs versus static) makes my exe's bigger than I would > like. In most of my applications, size isn't an issue - but in one in > particular - it is everything. Using shared linking in linux, which I think
It's better to help us increase effectiveness of smart linking ;-). > timeslice, which was my impression. I THINK that sleep refers to releasing > or yielding your entire application to other tasks the operating system is > handling. Which means its use should be minimal, and strategic - like when > you application true "should" release the CPU a bit... or is "truly" idle. I think Sleep is per-thread, not sure though. Anyway, you should never need Sleep; instead you should use mutexes or similar techniques to sleep until you need to wake up for calculation or whatever. > You see I have been playing with TThread - and I noticed that the most > currently launched thread is the one who stays running - and everything else > in my app stops until it finishes. This leads me to believe I am responsible How did you arrive at this conclusion ? It should not be so, the OS will do the scheduling for you, all threads will get their timeslice. > or some sort of mechanism. I believe TThread.Syncronize and possibly TThread > Critical Section are going to be my next area of experimentation. Critical sections are a sort of mutex indeed, about which I was talking above. > Along this lines I have changed the entire "main loop" architecture of my > bigger THREADING application - to work similar to how Lazarus makes its > executables or how a windows program works in win32 - I've built a messaging > system - that is a COMMON construct throughout all my classes, so that they > can ALL communicate in a context-less way to the main program - allowing the > main program to respond by suspending, resuming, terminating... etc any/all > of the working threads as it deems correct. Sounds like a good architecture. Micha _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal