Posix thread library is problematic.With WIN32?????
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)
Give me the functions that will do it, please. NtXXXX functions, and much much less than that, VxD/system utilities, do not count as Win32.
Under Win32 the thread scheduling is more robust, I've got more levelsI know neither the Win nor the Linux methods enough to comment.
of control between low, normal, and real time. (Without messing with the
scheduling type, FIFO, RR, etc)
What do you mean? Or did you refer to point E below?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.)
B. Events (posix conditions).A matter of taste, I suspect. Still, in what way? What do you want to do, and how does Event solve it?
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 disagree. fork+exec is far more feature rich then anything Windows can provide. The problem, I suspect, is one of mentality. The posix mentality is one of "less is more". You have one command to create a new process, and another to load a different program. If you want to load a different program as a new process, you use two commands. Simple as that + you gain the extra choices of creating a new process for the current program, or loading a new program using the current process. In addition, you gain total control over the new program's environment, file descriptors, etc. If you also want to change credentials in the process, you do just that (three command - fork, seteuid (or setuid), exec).C. Process. fork + exec, is far less effective and feature rich then CreateProcess (Or, CreateProcessAsUser, etc)
In windows, on the other hand, the most common case is the only one handled. Creating a new process IS loading a new program. You save 1 system call, but look at how much you pay for it:
* Creating a process is a different system call, depending on
whether you want to change credentials or not.
* Any function you choose will have so many parameters (usually
passed in stack), and have such side effects, that will be much
more difficult for the newcomer to get right (and some not so
newcomers).
* Running a program and waiting for it to return is over 40 lines of
code including the documentation that explains how to use the
function
(http://source.winehq.org/source/programs/wineboot/wineboot.c#L360
- don't use without understanding the license - this is LGPL code).
* Almost every time I have seen it implemented, it had some bug. The
code I quote above is a replacement to code Andreas Mohr wrote to
perform the same task. That code did not work! This is code I now
copy and paste verbatim between my projects, because I have lost
all hope of ever understanding it again.Compare that to:
if( !(pid=fork()) )
{
exec(....)
exit(-1);
} else
{
int status;
waitpid(pid, &status, 0);
}No function calls. If you want to asynchronously wait, you just set up a signal handler (or call waitpid with WNOHANG). A multi function operation produces a mutli function call, but an overall simpler code.
Isn't that an API that Sun are TAKING OUT of Solaris?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)
E. Wait functions.Does that still hold after this quote from MSDN?
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.
Use caution when calling the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. A thread that uses a wait function with no time-out interval may cause the system to become deadlocked. Two examples of code that indirectly creates windows are DDE and COM *CoInitialize* <http://msdn.microsoft.com/library/en-us/com/htm/cmf_a2c_36qt.asp>. Therefore, if you have a thread that creates windows, use *MsgWaitForMultipleObjects* <http://msdn.microsoft.com/library/en-us/dllproc/base/msgwaitformultipleobjects.asp> or *MsgWaitForMultipleObjectsEx* <http://msdn.microsoft.com/library/en-us/dllproc/base/msgwaitformultipleobjectsex.asp>, rather than *WaitForSingleObject*.Besides, which are you referring to. WaitForSingleObject, or WaitForSingleObjectEx? This is rather typical of Win32. You have a function that aims at doing every aspect of a certain operation. Then someone finds a new neuance, and you either modify the interface, or add a "Ex" function. Posix doesn't have Ex functions, because it tries to have every function do as little as possible.
For more information, see Using Mutex Objects <http://msdn.microsoft.com/library/en-us/dllproc/base/using_mutex_objects.asp>.
Besides, will WaitForSingleObject also handle TCP sockets? I don't remeber the last time I was trying to wait on file or mutex, without knowing which. I do remeber quite often trying to wait on a file descriptor without knowing whether it was a file, a pipe, or a TCP stream.
You were not flamed. You raised allegations. We said we thought you were wrong, and gave details. That is called "discussion".Oh. Here's something I don't get. Why can't one say a single word in favor of Windows without it being considered a flamebait?
Make no mistake, I rather work harder with less features at my handThat's where we think differently. I would rather work less hard with less features in my hand, then harder with more features in my hand, and this has nothing to do with the stability of the system.
under an stable and open environment (Linux) then to work with feature
rich APIs, that run under a close, unstable environment from hell.
(Windows, from MS...)
Windows API has over 15,000 (!!!!) APIs. How many of these do you know? Whenever there is something you need to do, unless you have already done it in the past, it always starts with a quest for the right function to use. Don't tell me there is wonderful documentation. MSDN is rife with inaccuracies, half informations and missing docs. Their interface used to be wonderful, and is slowly but surely becoming less and less usable. Several years ago I could open the bookset that had the info I was looking for, and look up the area that corresponded to what I wanted to do. Two years ago, getting to the right area by starting at the root was totally hopeless. I opened the index, and looked for the function. Half a year ago I could still type the name of the function (or a name of a function in the vicinity) into the search field, skip over all the CE stuff, until I found what I was looking for (usually, five of six entries down). In the past month, the best I could reach was to bookmark the page where all the functions are listed alphabetically, and jump there. I shudder to think what will happen in a year's time. MSDN has terrible index, and is getting worse as time passes.
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
================================================================= 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]
