How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Peter Olcott on 18 Mar 2010 14:33 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:r8i4q5tsodn2hvlb07381kbiuviq7dn1sf(a)4ax.com... > See below... > On Wed, 17 Mar 2010 14:21:36 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:fn42q59m8n702cpis6t409le60pdog0tft(a)4ax.com... >>> See below... >>> On Tue, 16 Mar 2010 21:06:35 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>message >>>>news:eyHxkRXxKHA.2644(a)TK2MSFTNGP04.phx.gbl... >>>>> Peter Olcott wrote: >>>>> >>>>>> >>>>>> That is not simple enough for my users. I want a >>>>>> browse >>>>>> button on a webpage that browses the local >>>>>> hard-drive. >>>>> >>>>> >>>>> <INPUT type="File" name="filename" /> >>>>> >>>>>> It seems that the only completely portable way to do >>>>>> this >>>>>> is HTML and this HTML is hooked up to CGI. Maybe I >>>>>> could >>>>>> build something from scratch at the other end to >>>>>> handle >>>>>> the input. I would guess that this would not provide >>>>>> any >>>>>> improvement over C++ FastCGI, and cost more >>>>>> development >>>>>> time. >>>>>> I am leaning toward Linux now, so a Microsoft thing >>>>>> ported to Linux may not be as good as a native Linux >>>>>> thing. >>>>> >>>>> Geez, you ain't going to get nothing done with this >>>>> lost >>>>> focus on "FastCGI". >>>>> >>>>> Once again, all you need is a standard C/C++ console >>>>> application that reads standard input to read your >>>>> HTTP >>>>> transfer encoded data block. You either write the >>>>> multi-part MIME processor or you get a library or >>>>> class >>>>> that does it for you. >>>> >>>>What handles transmission errors? Another thing, I want >>>>to >>>>immediately close the connection on the first packet if >>>>anything besides a 24-bit PNG file is detected. My app >>>>MUST >>>>be written in C++. I was envisioning this as a single >>>>app. >>>>One that handles the URL-encoded input, and the same one >>>>to >>>>process this data. In any case the one that processes >>>>this >>>>data must remain resident. >>> **** >>> You clearly missed any comprehsension of TCP/IP. TCP/IP >>> is as reliable as a piece of wire >>> between the two sites, and that essentially means it is >>> 100% utterly reliable, or it has >>> failed completely and there is no recovery (read about >>> how >>> TCP/IP retransmission works!) >>> so there are *no* "transmission errors" at all, or you >>> will get a notification that the >>> protocol has failed utterly and there is NO recovery >>> from >>> that, so browsers deal with it! >>> I have no idea what you are talking about when you talk >>> about "clos[ing] the connection on >>> the first packet" since, among other things, packets are >>> invisible at the application >>> level and you NEVER see them, you may or may not get all >>> the bits you want in one Receive >> >>OK so all this is new to me, We were talking about sockets >>which does deal with packets. > **** > No, we were talking about TCP/IP,w hich deals solely and > exclusively in BYTE STREAMs, and > packets are a low-level implementation detail NEVER seen > by the application socket > programmer! Noplace in any book on socket protramming > does it tell you that TCP/IP > delivers packets to you; they indicate the I/O is stream > oriented e.g., Comer & Stevens, > volume III, page 55, (one of the standard reference texts > on TCP/IP socket programming > that anyone who expects to do it should own), or Quinn & > Shute page 66 (another > fundamental book every socket programmer should own) > explicitly explain all this, very > carefully. Packets are a *transport* mechanism for > TCP/IP, and their existence is > completely gone by the time an application starts talking > to a socket. In this case, any > good introductory book on TCP/IP protocol (including > things like buffer management > piggybacking on ACK/NAK protocols, the sliding window > protocol, etc. are discusssed in any > goog introductory book on network programming) and the > conversion to streams is also > discussed. The role of blocking on send and recv are > dsicussed, and they are not related > to packets but to buffer management on the sender and > receiver. >> >>> (it is a STREAM transmission, and therefore you simply >>> CANNOT tell where packet boundaries >>> are or anything else, and MUST assume that it will take >>> 2 >>> or more Receives to get what you >>> need, and you have not identified what you mean by a >>> "24-bit PNG file is detected". You >> >>It would be located in the first 1K bytes of the file >>header. If I was dealing with packets, then I could >>examine >>the first one and potentially reject the rest. > **** > Streams are what they are, and you cannot presume you can > get ANY specific size on the > receiver side! Maybe you can get 1K bytes, and maybe you > get 986, or 852, or 711, or 254. > There's no way to predict, control, or rely on any > particular size being received. You > have to assume there will be arbitrary and unpredictable > breaks in the data, and what is > received as a single recv is in no way correlated with the > size of a send (for example, > you "send" 8192 bytes, but your first recv gives 1056 > bytes, and if so, this should not be > seen as surprising; you may have to execute several recv > calls to get that 8192 bytes, > pehaps as many as a dozen, perhaps as few as 2. Or maybe > even 1; unpredictable.) I have > no idea why you have developed this fascination with > "packets" since there is nothing in > the streaming socket API (that is, TCPI/IP) that > recognizes their existence. > > This is why it is worthwhile to do a little research > before jumping to conclusions, e.g., > that TCP/IP packets have any meaning at the application > level. > > You should probably read my sample code for a > multithreaded TCP/IP server from my MVP Tips > site. > joe It looks like I am going to be using HTTP as the protocol. I just bought two books on it. I am estimating that the TCP/IP is mostly invisible at the HTTP layer. I am using the HTTP protocol because it seems that the HTML element that I am using, sends the data using this protocol. <input name="userfile" type="file" accept="image/png" /> Using HTTP is it possible to reject a file that is the wrong format before the entire file is sent? Using HTTP is it possible to reject a file that is too large before very much of this file is sent? > **** >> >>> must be living in an alternate plane of existence wheere >>> there is some magic that >>> determines that because some magical bits appear at the >>> front of a byte sequence that the >>> rest of the sequence must necessarily conform to that >>> purported reality, and that in spite >>> of the fact that TCP/IP *guarantees* delivery of bits >>> intact that you might accidentally >>> see the wrong bits after the client makes a transmission >>> (this will never happen; TCP/IP >>> doesn't even allow for it!) which goes back to the >>> advice >>> I gave weeks ago, about reading >>> an introductory text on how TCP/IP actually works. >>> There >>> will be no "transmission errors" >> >>This might now be moot because it looks like I will be >>working at the higher level of HTTP, thus it seems that I >>will not be directly dealing with the TCP/IP. Hector has >>got me refocused on the webserver point of view. That >>seems >>fruitful. There is a very good freeware webserver that I >>can >>embed in my OCR processor, called mongoose. > **** > Note that you still have to address how to send files up > from the client, and establish > the protocol you will use, the encoding, etc., so you > are well on your way using a > custom server, having solved one (and only one) of the > numerous problem that you will have > to address. > **** Already addressed above. >> >>> that garbage the message; either the message is received >>> correctly or a fake message has >>> been sent, and if you have a fake message, you close the >>> connection and that's the end of >>> it. You go back and wait for the next connection. If >>> you >>> were using PHP and mime, you >>> would reject the data if it were not the correct mime >>> image, or, having read it, the >>> conversion to an image encountered a problem. It would >>> not be a transmission error; it >>> would be the result of erroneous data having been sent, >>> because you will receive >>> everything that was sent, perfectly, or you will be >>> notified that there has been an >>> unrecoverable network error (as will the transmission >>> side). This is inherent in the >>> TCP/IP protocol. >> >>OK good. So this low level details of this now seem out of >>the current scope of the project. > *** > Yes. They would have been ruled out long ago if you had > taken the time to read some good > books on TCP/IP and HTTP protocols. > joe > *** >> >>> >>> So forget the concept of "first packet" or even >>> "packets". >>> They are nonsense at the >>> TCP/IP application level. There is one, and only one, >>> reality: the byte sequence. If you >>> continue to believe in inappropriate (and erroneous) >>> concepts like "packets" when using >>> TCP/IP, you are DOOMED! They only have a reality at the >>> lowest levels of the protocol, >>> and at the application level, they have been erased >>> entirely from your awareness. People >>> who believe in anything other than the byte stream >>> eventually have problems. >> >>OK great good to have that cleared up. >> >>> >>> And please abandon your concepts of "resident", since >>> you >>> have demonstrated beyond any >>> possible doubt that you simply do not understand how >>> operating systems work. You have >>> these strange wishful-thinking models that have no >>> realization in any form of reality most >>> of us are familiar with, and you assume that operating >>> systems work in accordance to your >>> dreams and not the way they are actually implemented. >> >>I think that the 1000-fold faster than OCR performance >>that >>I achieve contradicts you on this. I can process an entire >>display screen in 1/10 second on a machine 800% slower >>than >>my current machine. This could not be achieved if my DFA >>was >>not at least almost completely contained with actual >>hardware memory. Also the 800% speed up is almost entirely >>attributed to faster access to physical RAM. > **** > Have you tried the experiment after letting the program > sit idle for 30 minutes? I think > you will see a completely different behavior pattern if > you exceed the working-set-paring > theshold time. One way or another (the least effort way) I will be able to make sure that my data remains (at least mostly) in physical RAM. I will address this later on, since this is merely an implementation detail. I always proceed with development using a strict hierarchy of increasing specificity. It is best to go this way because many of these details often become moot before final design is complete. > **** >> >>> **** >>>> >>>>> >>>>> If you write a PHP script, it will do it for you. You >>>>> can >>>>> put this under a FASTCGI PHP setup under a certain >>>>> port >>>>> and then write a HTTP client do do your testing. >>>>> >>>>> However, I don't believe PHP naturally supports memory >>>>> maps unless you find a public PHP class to expose the >>>>> WIN32 memory map functions. >>>>> >>>>> The WIN32 API has all the memory mapping functions and >>>>> you >>>>> will need this to handle the 4GB file. >>>>> >>>>> Now, on the wienie side, I don't know what it offers >>>>> for >>>>> memory mapping. But I am sure it has something >>>>> equivalent. >>>>> >>>>> -- >>>>> HLS >>>> >>>>I have no idea what you are talking about when referring >>>>to >>>>a memory map. It is not a 4.0 GB file, it is numerous >>>>files >>>>making up a total of 4.0 GB. >>> **** >>> Note that you cannot read a 4GB file into any WIndows >>> app, >>> since you only have 2GB (or >>> perhaps 3GB) of address space to use, and not all of >>> that >>> is available (your code, your >>> heap, and your stack, or each thread's stack, occupy the >>> same address space). Therefore, >>> you will HAVE to use a memory-mapped file if you wish to >>> access more data than you can >>> read. He is only pointing out the only possible >>> implementation that will let you access >>> 4GB of data effiiciently. If you think you can access >>> 4GB >>> of data, you can't even do that >>> in a Win32 app running in Win64 (which has a 4GB address >>> space, but not all of it can be >>> used for your data! See previous comment). If you can >>> currently read it all in, then you >>> don't have 4GB. >>> joe >> >>I have seen windows report that my 32-bit app was using > >>4000 MB of RAM. >>8.0 GB of Ram 64-bit Windows 7, and /LARGEADDRWESSAWARE >>This instance 4.0 GB is supposed to be the limit. >> >> http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_limits >> > **** > A 32-bit program cannot use more than 4GB of virtual > memory because it cannot address more > than 4GB of virtual memory. Any storage beyond this usage > is probably used by the 64-bit > system to hold paging tables and other process-related > resources, and as such would count > in the "memory footprint" of a 32-bit app running in a > Win64 enviornment. But that space > is not avialble to your program, because your Win32 > program is limited to being able to > name only 4GB of locations. > joe > **** >> >> >>> >>>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Mar 2010 17:41 Apparently you aren't paying attention. Windows will swap out pages of an idle process. You can see this if you have a lot of processes, and switch back to Word or PowerPoint, or VS; there is a huge delay in reactivation. even if none of the other processes have executed, because it has to bring in the pages of the working set before it can activate the thread. rather than guess at what you think should happen, rely on the experts, e.g., Russinovich & Solomon, WIndows Internals (5th edition) Micrsoft Press, 2009, start about page 812 ("Modified Page Writer") to understand how paging ACTUALLY works in Windows. Also read pp 822 ("WOrking Sets" and 823 ("Logical prefetcher"), page 824 which talks about the paging parameters in the Registry, page 828 ("Working Set Management") page 831 ("Balance Set Manager and Swapper") or page 836 ("Proactive Memory Management (SuperFetch)") or just read all of Chapter 9 ("Memory Management"). And it wouldn't hurt to read chapter 10 ("Cache Management"). You cannot pretend to be a serious developer who cares about WIndows Internals without owning this book. On Thu, 18 Mar 2010 11:03:23 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:u0h4q5l884o56c5ecd6hhnsb2fjci7j1vm(a)4ax.com... >> See below... >> On Wed, 17 Mar 2010 18:18:55 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>message news:47i2q5tch6oigbaqllh9lk0942mp5pnkt0(a)4ax.com... >>>> See below... >>>> On Tue, 16 Mar 2010 22:54:10 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> >>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>message >>>>>news:08i0q513cr5paa3m0mkvlmaoecd9vu7oqu(a)4ax.com... >>>>>> See below... >>>>>> On Tue, 16 Mar 2010 17:28:45 -0500, "Peter Olcott" >>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>> >>>>>>> >>>>>>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>>>>message >>>>>>>news:ea%23kdFVxKHA.5576(a)TK2MSFTNGP05.phx.gbl... >>>>>>>> Peter Olcott wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> I would be doing FastCGI in C++, if I do it. I am >>>>>>>>> considering FastCGI because I need a completely >>>>>>>>> portable >>>>>>>>> way for a user to browse for a PNG file to send to >>>>>>>>> my >>>>>>>>> server. HTML has this built in, and it is connected >>>>>>>>> to >>>>>>>>> CGI. As far as a protocol goes, this would be >>>>>>>>> trivial. >>>>>>>>> The user sends a 24-bit PNG file, the server sends >>>>>>>>> back >>>>>>>>> UTF-8. That's the whole protocol. Sometimes the >>>>>>>>> UTF-8 >>>>>>>>> is >>>>>>>>> the PNG file translated into text, and other times >>>>>>>>> it >>>>>>>>> is >>>>>>>>> an error response. >>>>>>>> >>>>>>>> Doesn't sound you understand, or at least are >>>>>>>> showing >>>>>>>> you >>>>>>>> don't, what FastCGI is. >>>>>>>> >>>>>>>> Forget fastcgi, what you need is a dedicated http >>>>>>>> server >>>>>>>> with the built-in procssing or a http server that >>>>>>>> supports >>>>>>>> spawning your cgi EXE application as a special URL. >>>>>>> >>>>>>>I can't take the several minutes of CGI process spawn >>>>>>>time >>>>>>>for my application, (it has to load gigabytes of data >>>>>>>into >>>>>>>memory before it begins) thus conventional CGI is >>>>>>>infeasible. >>>>>> *** >>>>>> So, in other words, if I happen to be so unfrotunate >>>>>> as >>>>>> to >>>>>> make a request on your server >>>>>> and there IS no instance of the process, that in fact, >>>>>> I >>>>>> cannot expect 500ms reponse time >>>>>> but instead can expect MINUTES of delay! >>>>>> >>>>>> NOte that all FASTCGI promises is that your process >>>>>> does >>>>>> not exist or require a restart >>>>>> once it has been launched; it does not promise the >>>>>> pages >>>>>> will be "held in memory". >>>>>> joe >>>>> >>>>>In actual practice operating systems typically do not >>>>>page >>>>>out code or data unless they need room for something >>>>>else. >>>>>This will be the only application on the dedicated >>>>>server, >>>>>thus little reason to be paged out. If necessary I will >>>>>run >>>>>a very tiny little background process that forces the >>>>>app >>>>>to >>>>>do something once in a while. >>>> *** >>>> In acutal practice, they DO page out out code or data >>>> "just in case", in fact, Windows has >>>> done this for years. So don't cite fictitious "actual >>>> practice" as your rationale. I'd >>>> ask a linux expert what linux does before presuming I >>>> knew >>>> what it did. In the history of >>>> operating systems, I've work on four (including WIndows) >>>> that paged out idle process pages >>>> on the general principle that if the process isn't being >>>> used, it shouldn't be taking up >>>> any space. So I'm curious where you learned aobut >>>> "actual >>>> practice" and why you believe >>>> this must be true. Unix was one of the three systems I >>>> used that did this, and VMS was >>>> another IBM's TSS/360 was the fourth. so my "actual >>>> practice" on real operating systems >>>> says the opposite of your concept of "actual practice", >>>> and I'm curious what OS you used >>>> that worked this way. And why you think you can >>>> generalize from one instance of one OS to >>>> believe that all operating systems must follow this >>>> pattern. >>>> joe >>> >>>Like I already said (in a message that you have not gotten >>>to yet) I can always force it to add up all of its pixels >>>every once in a while. For example whenever it is >>>otherwise >>>idle. This would require read access to every memory >>>location, thus keeping pages paged in. >> **** >> Only if you set the working set limits to not force it to >> page its own pages out! >> >> (You do know about working set, right? I've explained it >> in the past) >> joe > >Why is any of this complexity actually necessary in actual >practice? It would be absurd to be required these days when >so much RAM is available. If I always have 4.0 GB more than >I need either your whole point becomes moot, or OS design is >atrocious. > >> >>> >>>> **** >>>>> >>>> >>>>>> >>>>>> ***** >>>>>>> >>>>>>>> >>>>>>>> You will handle standard INPUT as the encoded data. >>>>>>>> Simple. >>>>>>>> >>>>>>>> Example: >>>>>>>> >>>>>>>> int main(char argc, char *argv[]) >>>>>>>> { >>>>>>>> DoCGI(); >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> where DoCgi() is reads stdin and maybe environment >>>>>>>> strings. >>>>>>>> >>>>>>>> int DoCGI() >>>>>>>> { >>>>>>>> // get environment string, if required >>>>>>>> // read stdin as FORM POSTING encoding data >>>>>>>> // process, generate response >>>>>>>> >>>>>>>> printf("Status: 200\n"); >>>>>>>> printf("Content-Type: text/text\n\n"); >>>>>>>> printf"UTF8:%s\n",szResponse); >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> For FastCGI, you would prepare your own socket >>>>>>>> listening >>>>>>>> server for incoming request from the web server >>>>>>>> itself. >>>>>>>> >>>>>>>> -- >>>>>>>> HLS >>>>>>> >>>>>> Joseph M. Newcomer [MVP] >>>>>> email: newcomer(a)flounder.com >>>>>> Web: http://www.flounder.com >>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Mar 2010 17:45 See below... On Thu, 18 Mar 2010 10:59:43 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Stephen Myers" ><""StephenMyers\"@discussions(a)microsoft.com"> wrote in >message news:O7Fz2UqxKHA.6140(a)TK2MSFTNGP05.phx.gbl... >> Peter Olcott wrote: >>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>> message >>> news:43b2q51hukg9s1gofoqds7vodf0lcq4bhp(a)4ax.com... >>>> See below... >>>> On Tue, 16 Mar 2010 22:19:25 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>> message >>>>> news:6ng0q5pbktq73efm697rl1tf18jv6dhknn(a)4ax.com... >>>>>> On Tue, 16 Mar 2010 20:16:44 -0500, "Peter Olcott" >>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>> >>>>>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>>>> message >>>>>>> news:ueIgi6WxKHA.1692(a)TK2MSFTNGP04.phx.gbl... >>>>>>>> Peter Olcott wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Fastest speed is highest priority, secondary to >>>>>>>>> this is >>>>>>>>> portability, it looks like FastCGI provides both. >>>>>>>>> Another very high priority is minimal development >>>>>>>>> costs. >>>>>>>>> As far as I can tell FastCGI is good here too. >>>>>>>> Dude, FastCGI is not a "Language." Its an idea, a >>>>>>>> methodology that was designed with EARLY needs to >>>>>>>> speed >>>>>>>> up >>>>>>>> loading time. You won't have that problem today. >>>>>>> You continue to ignore my repeatedly stated >>>>>>> requirement of >>>>>>> 4.0 GB of data (a deterministic finite automaton) >>>>>>> that >>>>>>> must >>>>>>> be loaded before execution can begin. If you ignore >>>>>>> my >>>>>>> fundamental requirements you can't possibly provide >>>>>>> good >>>>>>> advice. >>>>>> *** >>>>>> And you continue to ignore our observations that there >>>>>> are >>>>>> no technologies that guarantee >>>>>> this, and the timings of program behavior can be >>>>>> swamped >>>>>> by communication times (did I >>>>>> tell you about the 70-second DNS resolution time? Did >>>>>> you >>>>>> know that you can expect delays >>>>>> in integer number of seconds to locate your server?) >>>>>> >>>>> That is horrendous. I doubt if it is frequent, and >>>>> local >>>>> caching would hopefully prevent it from recurring. >>>> **** >>>> Depends. Did the end user configure for local DNS >>>> caching? WHat was the cache retention >>>> time set by the end user? Note, again, YOU HAVE NO >>>> CONTROL OVER THESE PARAMETERS! >>>> **** >>>>>> You fasten on some technology that says it is "faster" >>>>>> and >>>>>> assume it is the answer to your >>>>>> problem; you toss jargon around in ways that those of >>>>>> us >>>>>> who know the technology don't >>>>>> even recognize, such as assertions how FastCGI allows >>>>>> you >>>>>> to have browse buttons in the >>>>> It seems to me that most of you guys continue to simply >>>>> ignore some of my most fundamental design requirements. >>>>> App >>>>> load time for me can be several minutes, app execution >>>>> time >>>>> of a large job is never more than 100 milliseconds. >>>> ***** >>>> No, we hear them, we just don't believe that FastCGI is >>>> going to be the solution that will >>>> solve every issue for you. Hector says that CGI has >>>> been improved to where it has >>>> comparable performance to FastCGI. I have no >>>> information to confirm or deny that >>>> statement. Again, you are not a server expert, so you >>>> should pay attention to the server >>>> expert. >>>> **** >>>>> If the app is the only process besides the OS, by >>>>> limiting >>>>> memory usage to no more than 75% of available RAM in >>>>> actual >>>>> practice both the app and its data are paged out almost >>>>> not >>>>> at all. On a real-time OS this behavior would be >>>>> guaranteed. >>>>> On MS Windows it is close enough. Linux probably does >>>>> not do >>>>> worse than Windows in this regard. >>>> **** >>>> I have no idea why you think this is true. This is not >>>> an assumption I would have >>>> considered valid until I talked to a linux expert (since >>>> you will be hosted on linux). Yet >>>> you make this assertion simply because you THINK it >>>> should work, as opposed to getting >>>> data that confirms that the OS actually works this way. >>>> **** >>> >>> An OS that unloads any part of an executing process when >>> it has no need for additional memory would be an idiotic >>> OS. It would be flat out stupid to do this. I am not >>> convinced that either Windows or Linux is this stupid. >>> >>> If this same OS unloads part of a process because the >>> process has been idle for a long time, AND needs more >>> memory to do some housekeeping task, then this case I >>> could see a reason that would not be stupid. >>> >> Why should any OS keep all of your process in memory at >> all? The concept of paged virtual memory allows the OS to >> keep what's currently needed in memory. This allows 10 or >> 20 or 500 processes to have the illusion that their 2GB is >> resident whenever they're running. Consider a program >> that puts up a logo from a resource at startup. Should >> the OS keep that snippet (page) of memory in physical >> memory on the off chance that it will be needed again? > >In my particular instance the dedicated server will only >have the single purpose of running my OCR web application. >If I have to I will turn virtual memory off. It must keep my >process in memory even if I have to make changes to the OS >to achieve this. The simplest way that I can force the data >to remain resident, is to access every memory location >whenever my process is otherwise idle. **** And you know linux support this? And you know the host company will make the necessary configuration changes? joe **** > >> >>>>>> local Web server, and how it is the perfect answer to >>>>>> all >>>>>> your problems, when we know it >>>>>> isn't anything but another hack whose purpose is to >>>>>> compensate for bad initiali designs >>>>>> (CGI requiring a new process per request). You ignore >>>>>> core issues such as how you are >>>>>> going to port your app so it runs on a linux or Unix >>>>>> server, and how you are going to >>>>> I am rewriting it to require very little OS specific >>>>> code. >>>>> About the only thing that I will have to change is the >>>>> way >>>>> that PNG files are read into memory. I will have to >>>>> switch >>>>> to LibPNG. All of the MFC code is only development code >>>>> and >>>>> will not be part of production. >>>> **** >>>> PNG files would not be "read into memory"; instead, you >>>> will need to convert the input >>>> string (however it is provided, most likely via stdin) >>>> to a bitmap, and that requires a >>>> library that does not read the PNG data from a file but >>>> from a text stream. >>>> **** >>> >>> YES, or if I have to write is to disk and read it back in >>> again. Reading and writing 2K files will not kill me. >>> >>>>>> rewrite it to be platform-independent and possibly >>>>>> even >>>>>> GUI-free, and your unrealistic >>>>> The web service needs no GUI. It is all PNG in, and >>>>> UTF-8 >>>>> out. >>>> **** >>>> OK, that's good. You *will* have to write the FastCGI >>>> interface and make sure it works >>>> multithreaded so it can handle multiple requests. >>> >>> I am going with Hectors idea of a tiny embedded webserver >>> built in to my code. There are several freeware one's >>> one of these looks good enogh for my needs: mongoose. >>> >>>> **** >>>>>> expectations about how process memory is managed, and >>>>>> how >>>>>> every OS is magically going to >>>>>> behave in the way you wish, without any effort on your >>>>>> part. ANd you refuse to listen >>>>>> when people tell you that you don't understand either >>>>>> the >>>>>> technology or the intrinsic >>>>>> behavior of how an operating system works. >>>>>> >>>>>> You really need to do better research on these >>>>>> technologies before you start making such >>>>>> assertions, or ask questions and pay attention to the >>>>>> answers. I'm not even a Web server >>>>>> expert like Hector, and I can tell you are making >>>>>> nonsensical statements. Listen to him. >>>>>> He sounds like someone who does this for a living, and >>>>>> you >>>>>> should trust what he is telling >>>>>> you. >>>>>> joe >>>>> All that I know for sure is that some of my fundamental >>>>> requirements are immutable. Some of Hector's advice >>>>> seemed >>>>> to continue to ignore these requirements. I was >>>>> envisioning >>>>> the web service as a single application. This may not >>>>> have >>>>> been the way that he was envisioning it. >>>> **** >>>> You can do it by writing a "front end" that exports a >>>> known port and implements your >>>> appliction-specific protocol to get the data to send to >>>> your "business logic" component. >>>> It doesn't solve the paging problem, or the 4GB problem. >>>> joe >>> >>> I think that I will be going with some sort of >>> application specific webserver such as mongoose. Hector >>> tried to sell me on his webserver, but, it was too costly >>> and not flexible enough for me right now. In the future >>> when I scale up to multiple servers this may change. >>> >>>> **** >>>>>>>> Its nonsense to think this is "answer" to >>>>>>>> your problem. In addition, if you worry about >>>>>>>> processing >>>>>>>> speed, native C/C++ is your choice, so all you are >>>>>>>> doing >>>>>>>> is writing a CGI application, a console application >>>>>>>> that >>>>>>>> reads standard input. >>>>>>>> >>>>>>>> If you want productivity, learn PHP. Simple, well >>>>>>>> supported. Then if you really find out that FASTCGI >>>>>>>> is >>>>>>>> needed for your slow OS and machine, PHP supports >>>>>>>> it. >>>>>>>> >>>>>>>> The point is your SOLUTION is not FASTCGI, it is the >>>>>>>> actual application that does the work. >>>>>>>> >>>>>>>> -- >>>>>>>> HLS >>>>>> Joseph M. Newcomer [MVP] >>>>>> email: newcomer(a)flounder.com >>>>>> Web: http://www.flounder.com >>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Mar 2010 17:46 See below... On Thu, 18 Mar 2010 11:12:36 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:f9h4q5ltbdi70eot2n5me08gij5vg556bc(a)4ax.com... >> See below... >> On Wed, 17 Mar 2010 15:04:40 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>message news:43b2q51hukg9s1gofoqds7vodf0lcq4bhp(a)4ax.com... >>>> See below... >>>> On Tue, 16 Mar 2010 22:19:25 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> >>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>message >>>>>news:6ng0q5pbktq73efm697rl1tf18jv6dhknn(a)4ax.com... >>>>>> On Tue, 16 Mar 2010 20:16:44 -0500, "Peter Olcott" >>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>> >>>>>>> >>>>>>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>>>>message >>>>>>>news:ueIgi6WxKHA.1692(a)TK2MSFTNGP04.phx.gbl... >>>>>>>> Peter Olcott wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Fastest speed is highest priority, secondary to >>>>>>>>> this >>>>>>>>> is >>>>>>>>> portability, it looks like FastCGI provides both. >>>>>>>>> Another very high priority is minimal development >>>>>>>>> costs. >>>>>>>>> As far as I can tell FastCGI is good here too. >>>>>>>> >>>>>>>> Dude, FastCGI is not a "Language." Its an idea, a >>>>>>>> methodology that was designed with EARLY needs to >>>>>>>> speed >>>>>>>> up >>>>>>>> loading time. You won't have that problem today. >>>>>>> >>>>>>>You continue to ignore my repeatedly stated >>>>>>>requirement >>>>>>>of >>>>>>>4.0 GB of data (a deterministic finite automaton) that >>>>>>>must >>>>>>>be loaded before execution can begin. If you ignore my >>>>>>>fundamental requirements you can't possibly provide >>>>>>>good >>>>>>>advice. >>>>>> *** >>>>>> And you continue to ignore our observations that there >>>>>> are >>>>>> no technologies that guarantee >>>>>> this, and the timings of program behavior can be >>>>>> swamped >>>>>> by communication times (did I >>>>>> tell you about the 70-second DNS resolution time? Did >>>>>> you >>>>>> know that you can expect delays >>>>>> in integer number of seconds to locate your server?) >>>>>> >>>>> >>>>>That is horrendous. I doubt if it is frequent, and local >>>>>caching would hopefully prevent it from recurring. >>>> **** >>>> Depends. Did the end user configure for local DNS >>>> caching? WHat was the cache retention >>>> time set by the end user? Note, again, YOU HAVE NO >>>> CONTROL OVER THESE PARAMETERS! >>>> **** >>>>> >>>>>> You fasten on some technology that says it is "faster" >>>>>> and >>>>>> assume it is the answer to your >>>>>> problem; you toss jargon around in ways that those of >>>>>> us >>>>>> who know the technology don't >>>>>> even recognize, such as assertions how FastCGI allows >>>>>> you >>>>>> to have browse buttons in the >>>>> >>>>>It seems to me that most of you guys continue to simply >>>>>ignore some of my most fundamental design requirements. >>>>>App >>>>>load time for me can be several minutes, app execution >>>>>time >>>>>of a large job is never more than 100 milliseconds. >>>> ***** >>>> No, we hear them, we just don't believe that FastCGI is >>>> going to be the solution that will >>>> solve every issue for you. Hector says that CGI has >>>> been >>>> improved to where it has >>>> comparable performance to FastCGI. I have no >>>> information >>>> to confirm or deny that >>>> statement. Again, you are not a server expert, so you >>>> should pay attention to the server >>>> expert. >>>> **** >>>>> >>>>>If the app is the only process besides the OS, by >>>>>limiting >>>>>memory usage to no more than 75% of available RAM in >>>>>actual >>>>>practice both the app and its data are paged out almost >>>>>not >>>>>at all. On a real-time OS this behavior would be >>>>>guaranteed. >>>>>On MS Windows it is close enough. Linux probably does >>>>>not >>>>>do >>>>>worse than Windows in this regard. >>>> **** >>>> I have no idea why you think this is true. This is not >>>> an >>>> assumption I would have >>>> considered valid until I talked to a linux expert (since >>>> you will be hosted on linux). Yet >>>> you make this assertion simply because you THINK it >>>> should >>>> work, as opposed to getting >>>> data that confirms that the OS actually works this way. >>>> **** >>> >>>An OS that unloads any part of an executing process when >>>it >>>has no need for additional memory would be an idiotic OS. >>>It >>>would be flat out stupid to do this. I am not convinced >>>that >>>either Windows or Linux is this stupid. >> *** >> But we learned DECADES ago that "eager page-out" improves >> overall system performance, >> because it reduces startup transients when a process (or >> one of its threads) becomes >> schedulable. Again, the "working set" has to be paged in, >> and this is easier if there are >> available page frames in memory. So what you are calling >> "stupid" is in fact the >> DEMONSTRATED INTELLIGENT way to build operating systems, >> and we've known this since they >> early 1970s. This is why I have never known a system that >> did not page out an idle >> process IN ANITICIPATION OF NEED. Windows does it; I'm >> trying to find out if linux does >> it, but again, your opinion of how you THINK an operating >> system SHOULD work flies in the >> fact of reality. Just because you don't see a reason >> doesn't mean there isn't one, and >> one that has been established by long practice (the >> "actual practice" you fantasize about >> doesn't exist). Windows indeed works this way, and so >> have other operating systems, all >> based on BEST practice (not someone's fantasized "actual >> practice"). So I would not >> predicate actual behavior on fantasies, but learn the >> facts. >> ***** > >I will simply do whatever it takes to achieve the functional >result that I require. If there is always an extra 4.0 GB of >RAM available, then your whole anticipation of need concept >should become moot. > **** Maybe. You are still basing this on wishful thinking of what you think OUGHT to happen, rather than finding out what the real operating system does.... joe **** >>> >>>If this same OS unloads part of a process because the >>>process has been idle for a long time, AND needs more >>>memory >>>to do some housekeeping task, then this case I could see a >>>reason that would not be stupid. >> **** >> It is the antiipation-of-need which in actual practice >> (not fantasized "actual practive", >> but ACTUAL practice) has been found to be the best >> solution for general purpose operating >> systems, to maximize overall performance. Until you have >> measured (there's that nasty >> phrase, implying the obtaining of facts) behavior, you >> have no reason to assume it >> corresponds to your fantasies. >> **** >>> >>>>> >>>>>> local Web server, and how it is the perfect answer to >>>>>> all >>>>>> your problems, when we know it >>>>>> isn't anything but another hack whose purpose is to >>>>>> compensate for bad initiali designs >>>>>> (CGI requiring a new process per request). You ignore >>>>>> core issues such as how you are >>>>>> going to port your app so it runs on a linux or Unix >>>>>> server, and how you are going to >>>>> >>>>>I am rewriting it to require very little OS specific >>>>>code. >>>>>About the only thing that I will have to change is the >>>>>way >>>>>that PNG files are read into memory. I will have to >>>>>switch >>>>>to LibPNG. All of the MFC code is only development code >>>>>and >>>>>will not be part of production. >>>> **** >>>> PNG files would not be "read into memory"; instead, you >>>> will need to convert the input >>>> string (however it is provided, most likely via stdin) >>>> to >>>> a bitmap, and that requires a >>>> library that does not read the PNG data from a file but >>>> from a text stream. >>>> **** >>> >>>YES, or if I have to write is to disk and read it back in >>>again. Reading and writing 2K files will not kill me. >>> >>>>> >>>>>> rewrite it to be platform-independent and possibly >>>>>> even >>>>>> GUI-free, and your unrealistic >>>>> >>>>>The web service needs no GUI. It is all PNG in, and >>>>>UTF-8 >>>>>out. >>>> **** >>>> OK, that's good. You *will* have to write the FastCGI >>>> interface and make sure it works >>>> multithreaded so it can handle multiple requests. >>> >>>I am going with Hectors idea of a tiny embedded webserver >>>built in to my code. There are several freeware one's one >>>of these looks good enogh for my needs: mongoose. >>> >>>> **** >>>>> >>>>>> expectations about how process memory is managed, and >>>>>> how >>>>>> every OS is magically going to >>>>>> behave in the way you wish, without any effort on your >>>>>> part. ANd you refuse to listen >>>>>> when people tell you that you don't understand either >>>>>> the >>>>>> technology or the intrinsic >>>>>> behavior of how an operating system works. >>>>>> >>>>>> You really need to do better research on these >>>>>> technologies before you start making such >>>>>> assertions, or ask questions and pay attention to the >>>>>> answers. I'm not even a Web server >>>>>> expert like Hector, and I can tell you are making >>>>>> nonsensical statements. Listen to him. >>>>>> He sounds like someone who does this for a living, and >>>>>> you >>>>>> should trust what he is telling >>>>>> you. >>>>>> joe >>>>> >>>>>All that I know for sure is that some of my fundamental >>>>>requirements are immutable. Some of Hector's advice >>>>>seemed >>>>>to continue to ignore these requirements. I was >>>>>envisioning >>>>>the web service as a single application. This may not >>>>>have >>>>>been the way that he was envisioning it. >>>> **** >>>> You can do it by writing a "front end" that exports a >>>> known port and implements your >>>> appliction-specific protocol to get the data to send to >>>> your "business logic" component. >>>> It doesn't solve the paging problem, or the 4GB problem. >>>> joe >>> >>>I think that I will be going with some sort of application >>>specific webserver such as mongoose. Hector tried to sell >>>me >>>on his webserver, but, it was too costly and not flexible >>>enough for me right now. In the future when I scale up to >>>multiple servers this may change. >>> >>>> >>>> **** >>>>> >>>>>> >>>>>>> >>>>>>> > Its nonsense to think this is "answer" to >>>>>>>> your problem. In addition, if you worry about >>>>>>>> processing >>>>>>>> speed, native C/C++ is your choice, so all you are >>>>>>>> doing >>>>>>>> is writing a CGI application, a console application >>>>>>>> that >>>>>>>> reads standard input. >>>>>>>> >>>>>>>> If you want productivity, learn PHP. Simple, well >>>>>>>> supported. Then if you really find out that FASTCGI >>>>>>>> is >>>>>>>> needed for your slow OS and machine, PHP supports >>>>>>>> it. >>>>>>>> >>>>>>>> The point is your SOLUTION is not FASTCGI, it is the >>>>>>>> actual application that does the work. >>>>>>>> >>>>>>>> -- >>>>>>>> HLS >>>>>>> >>>>>> Joseph M. Newcomer [MVP] >>>>>> email: newcomer(a)flounder.com >>>>>> Web: http://www.flounder.com >>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 18 Mar 2010 18:33
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:k245q592jsdhrhg1ccberqg1440ltvv0fr(a)4ax.com... > Apparently you aren't paying attention. Windows will swap > out pages of an idle process. > You can see this if you have a lot of processes, and > switch back to Word or PowerPoint, or > VS; there is a huge delay in reactivation. even if none of > the other processes have > executed, because it has to bring in the pages of the > working set before it can activate > the thread. So why would not simply keeping it always active with busy work (whenever it would be otherwise idle) solve my problem? I will try your little half hour thing. I am guessing that your experience with this issue is derived from not having plenty of excess RAM. > > rather than guess at what you think should happen, rely on > the experts, e.g., Russinovich > & Solomon, WIndows Internals (5th edition) Micrsoft Press, > 2009, start about page 812 > ("Modified Page Writer") to understand how paging ACTUALLY > works in Windows. Also read pp > 822 ("WOrking Sets" and 823 ("Logical prefetcher"), page > 824 which talks about the paging > parameters in the Registry, page 828 ("Working Set > Management") page 831 ("Balance Set > Manager and Swapper") or page 836 ("Proactive Memory > Management (SuperFetch)") or just > read all of Chapter 9 ("Memory Management"). And it > wouldn't hurt to read chapter 10 > ("Cache Management"). > > You cannot pretend to be a serious developer who cares > about WIndows Internals without > owning this book. I care about windows internals about as much as my mother cares about the details of how her car's transmission works. I just want my OS to work, I don't care how it works. When what I need it to do requires me to gain some understanding about how it works, I gain just the bare minimum required to get the job done. I am not at all interesting in memorizing thousands of obscure facts, what I am interested in is creating new software technology. > On Thu, 18 Mar 2010 11:03:23 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:u0h4q5l884o56c5ecd6hhnsb2fjci7j1vm(a)4ax.com... >>> See below... >>> On Wed, 17 Mar 2010 18:18:55 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>message >>>>news:47i2q5tch6oigbaqllh9lk0942mp5pnkt0(a)4ax.com... >>>>> See below... >>>>> On Tue, 16 Mar 2010 22:54:10 -0500, "Peter Olcott" >>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>> >>>>>> >>>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>>message >>>>>>news:08i0q513cr5paa3m0mkvlmaoecd9vu7oqu(a)4ax.com... >>>>>>> See below... >>>>>>> On Tue, 16 Mar 2010 17:28:45 -0500, "Peter Olcott" >>>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>>> >>>>>>>> >>>>>>>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>>>>>message >>>>>>>>news:ea%23kdFVxKHA.5576(a)TK2MSFTNGP05.phx.gbl... >>>>>>>>> Peter Olcott wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I would be doing FastCGI in C++, if I do it. I am >>>>>>>>>> considering FastCGI because I need a completely >>>>>>>>>> portable >>>>>>>>>> way for a user to browse for a PNG file to send >>>>>>>>>> to >>>>>>>>>> my >>>>>>>>>> server. HTML has this built in, and it is >>>>>>>>>> connected >>>>>>>>>> to >>>>>>>>>> CGI. As far as a protocol goes, this would be >>>>>>>>>> trivial. >>>>>>>>>> The user sends a 24-bit PNG file, the server >>>>>>>>>> sends >>>>>>>>>> back >>>>>>>>>> UTF-8. That's the whole protocol. Sometimes the >>>>>>>>>> UTF-8 >>>>>>>>>> is >>>>>>>>>> the PNG file translated into text, and other >>>>>>>>>> times >>>>>>>>>> it >>>>>>>>>> is >>>>>>>>>> an error response. >>>>>>>>> >>>>>>>>> Doesn't sound you understand, or at least are >>>>>>>>> showing >>>>>>>>> you >>>>>>>>> don't, what FastCGI is. >>>>>>>>> >>>>>>>>> Forget fastcgi, what you need is a dedicated http >>>>>>>>> server >>>>>>>>> with the built-in procssing or a http server that >>>>>>>>> supports >>>>>>>>> spawning your cgi EXE application as a special >>>>>>>>> URL. >>>>>>>> >>>>>>>>I can't take the several minutes of CGI process >>>>>>>>spawn >>>>>>>>time >>>>>>>>for my application, (it has to load gigabytes of >>>>>>>>data >>>>>>>>into >>>>>>>>memory before it begins) thus conventional CGI is >>>>>>>>infeasible. >>>>>>> *** >>>>>>> So, in other words, if I happen to be so unfrotunate >>>>>>> as >>>>>>> to >>>>>>> make a request on your server >>>>>>> and there IS no instance of the process, that in >>>>>>> fact, >>>>>>> I >>>>>>> cannot expect 500ms reponse time >>>>>>> but instead can expect MINUTES of delay! >>>>>>> >>>>>>> NOte that all FASTCGI promises is that your process >>>>>>> does >>>>>>> not exist or require a restart >>>>>>> once it has been launched; it does not promise the >>>>>>> pages >>>>>>> will be "held in memory". >>>>>>> joe >>>>>> >>>>>>In actual practice operating systems typically do not >>>>>>page >>>>>>out code or data unless they need room for something >>>>>>else. >>>>>>This will be the only application on the dedicated >>>>>>server, >>>>>>thus little reason to be paged out. If necessary I >>>>>>will >>>>>>run >>>>>>a very tiny little background process that forces the >>>>>>app >>>>>>to >>>>>>do something once in a while. >>>>> *** >>>>> In acutal practice, they DO page out out code or data >>>>> "just in case", in fact, Windows has >>>>> done this for years. So don't cite fictitious "actual >>>>> practice" as your rationale. I'd >>>>> ask a linux expert what linux does before presuming I >>>>> knew >>>>> what it did. In the history of >>>>> operating systems, I've work on four (including >>>>> WIndows) >>>>> that paged out idle process pages >>>>> on the general principle that if the process isn't >>>>> being >>>>> used, it shouldn't be taking up >>>>> any space. So I'm curious where you learned aobut >>>>> "actual >>>>> practice" and why you believe >>>>> this must be true. Unix was one of the three systems >>>>> I >>>>> used that did this, and VMS was >>>>> another IBM's TSS/360 was the fourth. so my "actual >>>>> practice" on real operating systems >>>>> says the opposite of your concept of "actual >>>>> practice", >>>>> and I'm curious what OS you used >>>>> that worked this way. And why you think you can >>>>> generalize from one instance of one OS to >>>>> believe that all operating systems must follow this >>>>> pattern. >>>>> joe >>>> >>>>Like I already said (in a message that you have not >>>>gotten >>>>to yet) I can always force it to add up all of its >>>>pixels >>>>every once in a while. For example whenever it is >>>>otherwise >>>>idle. This would require read access to every memory >>>>location, thus keeping pages paged in. >>> **** >>> Only if you set the working set limits to not force it >>> to >>> page its own pages out! >>> >>> (You do know about working set, right? I've explained >>> it >>> in the past) >>> joe >> >>Why is any of this complexity actually necessary in actual >>practice? It would be absurd to be required these days >>when >>so much RAM is available. If I always have 4.0 GB more >>than >>I need either your whole point becomes moot, or OS design >>is >>atrocious. >> >>> >>>> >>>>> **** >>>>>> >>>>> >>>>>>> >>>>>>> ***** >>>>>>>> >>>>>>>>> >>>>>>>>> You will handle standard INPUT as the encoded >>>>>>>>> data. >>>>>>>>> Simple. >>>>>>>>> >>>>>>>>> Example: >>>>>>>>> >>>>>>>>> int main(char argc, char *argv[]) >>>>>>>>> { >>>>>>>>> DoCGI(); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> where DoCgi() is reads stdin and maybe environment >>>>>>>>> strings. >>>>>>>>> >>>>>>>>> int DoCGI() >>>>>>>>> { >>>>>>>>> // get environment string, if required >>>>>>>>> // read stdin as FORM POSTING encoding data >>>>>>>>> // process, generate response >>>>>>>>> >>>>>>>>> printf("Status: 200\n"); >>>>>>>>> printf("Content-Type: text/text\n\n"); >>>>>>>>> printf"UTF8:%s\n",szResponse); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> For FastCGI, you would prepare your own socket >>>>>>>>> listening >>>>>>>>> server for incoming request from the web server >>>>>>>>> itself. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> HLS >>>>>>>> >>>>>>> Joseph M. Newcomer [MVP] >>>>>>> email: newcomer(a)flounder.com >>>>>>> Web: http://www.flounder.com >>>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>>>> >>>>> Joseph M. Newcomer [MVP] >>>>> email: newcomer(a)flounder.com >>>>> Web: http://www.flounder.com >>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |