Posix thread library is problematic.
Here's a couple of examples.
A. Threads: Lack of true, low level, thread control.
For instance, in Win32 I can save a thread's context, suspend it
remotely (from another thread or even a controlling process) implant the
saved context into it, and it'll continue running from the were I
stopped it. (Kind'a like hardware interrupt)
ptrace(2) says:
" PTRACE_PEEKTEXT, PTRACE_PEEKDATA
Reads a word at the location addr in the child's
memory, returning the word as the result of the
ptrace call. Linux does not have separate text and
data address spaces, so the two requests are cur-
rently equivalent. (The argument data is ignored.) PTRACE_PEEKUSR
Reads a word at offset addr in the child's USER
area, which holds the registers and other informa-
tion about the process (see <linux/user.h> and
<sys/user.h>). The word is returned as the result
of the ptrace call. Typically the offset must be
word-aligned, though this might vary by architec-
ture. (data is ignored.)"The equivilient POKE functions exists as well.
Under Win32 the thread scheduling is more robust, I've got more levels
of control between low, normal, and real time. (Without messing with the
scheduling type, FIFO, RR, etc)
POSIX provides 100 levels of real time scheduling + a dynamic priority for normal/low proccess and teh addtional ability to pick the scheduling algorythm used to pick the next task, changable at run time.
Care to eloborate which feature are you missing?
Oh, and the lack of true smart wait function is problematic. (I usually create a mutex that goes with a thread to emulate a true thread wait function.)
What is the additional features which the smart wait function provides above a mutex?
B. Events (posix conditions). Wait it doesn't work right (PulseEvent never did... MS, like MS, just refuses to fix it), NT events are much easier to use, and have much better control. The posix conditions are a just pain in the back side.
I don't understand the issue, so I'll jsut shut up...
C. Process. fork + exec, is far less effective and feature rich then CreateProcess (Or, CreateProcessAsUser, etc)
How much of that added functionality is ever used in 99.5% of the uses of that function? how many programers understnad the model involved?
D. Process, Thread control. Lack of Affinity mask (Ability to divert a single process / thread to be used on CPUn,y,z outside the OS's discretions)
CPU affinity is available under Linux, at least.
E. Wait functions.
WaitForSingleObject (WaitForMulitpleObjects) is by far better then
anything posix. The ability to create a single wait that will work on
threads, processes, files, events, mutexes, etc, is a true blessing.
I'm currently looking into ways to emulate the WaitFor* on posix
machines.
Yes, you're right there. Will you release the code as GPL when you're done? :-)
Yes, Microsoft have in their time, done a lot of very good things and some pretty stupid ones. What made me leave the M$ world and turn to Unix/Posix/Linux as that i didn't like the need to rel-earn everything I knew every 2 years. It's tuff to learn Unix, but once you do you can use the knowledge for years. I did not expreince this under the M$ regime and it can even be claim that it's by design.
Gilad
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
