From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:kl75q5pr3846rc6m4iiqad958ccoanrlba(a)4ax.com...
> 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?

If Linux has threads, then it must support this. If it does
not have threads then IPC from another process would support
this.

>
> And you know the host company will make the necessary
> configuration changes?
> joe

Its only a tedious detail. I can always do the whole thing
myself (buy my own connection to the web) as a last resort,
its not really all that difficult. I am betting that the
half hour test will pass.

> ****
>>
>>>
>>>>>>> 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: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:vn75q5dpobop8jk9r1qllphrm4a2p36mpn(a)4ax.com...
> 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 it does not work this way, I will find one way or another
to make it work this way. I have never seen it not work this
way in my 26 years of professional experience.

>
> ****
>>>>
>>>>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: Hector Santos on
On Mar 18, 6:47 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:

> I still have every email message that I have ever received
> (including attachments) in the last six years and they are
> taking up 2% of my 1 GB allocated server space.

Yeah, and your input is about 0.023% of the new storage of quoted
wasted bandwidth. I just did a download of your last 3 post you made
and let me count.....

- 3 messages
- 1087 lines
- 26 lines of new input by you

Thats 0.023% or 99.98% waste of communications bandwidth and wasted
CPU power required by hundreds of thousands, if not millions of news
gate systems and readers.

Hey, I personally don't care if top posting or inline quoting is used,
it is over quoting of all the non-relevant text that makes all hard to
read and not truncating the remainder of the quote is well, very odd.
From: Geoff on
On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott"
<NoSpam(a)OCR4Screen.com> wrote:

>Yes and it also looks like converting to 64-bit will cost
>very little system resources. I was thinking that
>std::vector elements would increase in size by four bytes.
>With further consideration this would seem to not be the
>case.

The STL was written for 32 bits. Unless there has been a change to the
standard to accommodate 64 bits you will be limited. In any case, for
now it is implementation dependent.

Beware vector.max_size(), it returns a 32 bit value but on Win32 it's
impossible to use vectors up to max_size() for lack of memory
capacity. The STL implementation has no knowledge about the OS
limitations. A Win32 app running in Win64 might be able to make full
use of max_size() but you will need to test it. The templates fail in
exactly the same way on Linux32 platforms with all the GCC
implementations I have tested.
From: Peter Olcott on

"Geoff" <geoff(a)invalid.invalid> wrote in message
news:nvg5q59n1229l8k3baqtq7r77pk59q59f6(a)4ax.com...
> On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott"
> <NoSpam(a)OCR4Screen.com> wrote:
>
>>Yes and it also looks like converting to 64-bit will cost
>>very little system resources. I was thinking that
>>std::vector elements would increase in size by four bytes.
>>With further consideration this would seem to not be the
>>case.
>
> The STL was written for 32 bits. Unless there has been a
> change to the
> standard to accommodate 64 bits you will be limited. In
> any case, for
> now it is implementation dependent.
>
> Beware vector.max_size(), it returns a 32 bit value but on
> Win32 it's
> impossible to use vectors up to max_size() for lack of
> memory
> capacity. The STL implementation has no knowledge about
> the OS
> limitations. A Win32 app running in Win64 might be able to
> make full
> use of max_size() but you will need to test it. The
> templates fail in
> exactly the same way on Linux32 platforms with all the GCC
> implementations I have tested.

No problem I have already written std::vector from scratch
once, so I could do it again. The platform specific aspect
would be limited by whatever malloc() could handle. "new" is
probably implemented using malloc().

I wanted to have a std::vector on my Borland Turbo C++ 1.01
to run on my handheld HP 200LX. The std::vector stuff was
pretty easy, the hard part was implementing a generic
std::vector without the use of templates. I wrote the
std::vector after I beat out the vendor's (Borland C++
Builder 4.0 and Microsoft VC++ 6.0) implementation of
std::string by about 50-fold increase in speed.