On Tue, 2003-06-03 at 12:17, Shachar Shemesh wrote: > Gilboa Davara wrote: > > >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) > > > With WIN32????? > > 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.
Actually these are normal, run of the mill, Win32 functions... SuspendThread GetThreadContext ResumeThread SuspendThread SetThreadContext ResumeThread Nice, isn't it? > > >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) > > > I know neither the Win nor the Linux methods enough to comment. > > >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 do you mean? Or did you refer to point E below? Yep. > > >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. > > > > > A matter of taste, I suspect. Still, in what way? What do you want to > do, and how does Event solve it? > > >C. Process. > >fork + exec, is far less effective and feature rich then CreateProcess > >(Or, CreateProcessAsUser, etc) > > > 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). I'm willing to agree on that one. However, at least for me, the ability to exchange 20 (or so) commands with a single CreateProcess command is a nice time saver. > > 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. I just need to use: fork, chdir, setpriority, dup2 (divert stdin/out/err), exec, waitpid, sleep, waitpid (or just waitpid without WNOHANG), etc. All of this is being replaced by CreateProcess and WaitForXXXObjects. > >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) > > > Isn't that an API that Sun are TAKING OUT of Solaris? I'm doing my best to avoid Solaris at all cost :-) > > >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. > > > Does that still hold after this quote from MSDN? > > > 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*. > > > > For more information, see Using Mutex Objects > > <http://msdn.microsoft.com/library/en-us/dllproc/base/using_mutex_objects.asp>. > > > > I know what they're referring too. GDI function create a separate message queue (so called WndProc) that can send the machine to hell if used incorrectly in conjunction with the normal handle messaging (implementation again). If I remember correctly, in the case above you'll have 100% CPU utilization (kinda like while (1);) which, if you run at real time priority, will hard lock the machine. BTW, the same can be achieved by using SCHED_RR and real time thread scheduling under Linux. (There no OS in existence, that can stop a dumb programmer with admin rights from sending it to hell...) > 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. Actually I'm in-favor of the Ex system. I even use it myself. It keeps your library binary compatible with older versions. The developers who use(d) my libraries always thanked me for that :-) > > Besides, will WaitForSingleObject also handle TCP sockets? I don't There's an odd way of doing it. But essentially, no. > 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. Ummm.... never happened to me... but hey... > > >>>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? > >>> > You were not flamed. You raised allegations. We said we thought you were > wrong, and gave details. That is called "discussion". > > >Make no mistake, I rather work harder with less features at my hand > >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...) > > > > > That'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. > > Windows API has over 15,000 (!!!!) APIs. How many of these do you know? A nice portion of it. (5%...) > 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. Actually I find the MSDN to be effective just as man pages. Both are helpful... at least in my eyes. (Though in the end, google is better then them both...) > > Shachar Anyways, Considering how much I hate Microsoft and how much I loath the idea of porting some of my current code from posix back to Windows, I find the job of playing the devil's advocate (Microsoft) to have a negative effect on my health. Like the chicken that I am (and always been), I'm leaving the jobs to others :-) -- Take care, Gilboa Davara XML - Systems Israel. mailto:[EMAIL PROTECTED] ================================================================= 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]
