«

I wrote some simple code that forks processes and sends http requests
from the children. I have read the perlfork documentation and
understand that Windows uses "fork umulation" (with threads) rather
than actually forking processes (like you can in *nix). I am
wondering if anyone has any experience of the limitations of how many
processes can be forked? I get memory errors at 10 processes (in
comparison, I can fork several hundred on linux with no problems).

in the perlfork doc: "In the eyes of the operating system,
pseudo-processes created via the fork() emulation are simply threads
in the same process. This means that any process-level limits imposed
by the operating system apply to all pseudo-processes taken together.
This includes any limits imposed by the operating system on the number
of open file, directory and socket handles, limits on disk space
usage, limits on memory size, limits on CPU utilization etc."

I don't see how I could be hitting any limits at such a small number
of processes.

[using ActiveState Perl 5.8 on Win2k)


-Corey Goldberg

Purl Gurl wrote:

> For NT5, if a typical machine, you are using close
> to one-third upwards to one-half of your system
> resources simply running your NT5 kernal and Win GUI.

I haven't used a Windows system in quite some time, but if I recall
correctly, System Resources (in the Windows sense of the phrase) could only
be stored in the first 1MB of memory.

Is that what you're referring to here? If so, I'm mildly surprised - I would
have thought the NT5/2k/XP kernels would have gotten past that. Only mildly
suprised though - it *is* MS we're talking about.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Purl Gurl wrote:

> That is very close to true forking under Windows.

I was aware that forking was emulated with threads under Windows, but not of
so many of the details. Thanks for filling in the gaps.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Sherm Pendley () wrote:
: Purl Gurl wrote:

: > For NT5, if a typical machine, you are using close
: > to one-third upwards to one-half of your system
: > resources simply running your NT5 kernal and Win GUI.

: I haven't used a Windows system in quite some time, but if I recall
: correctly, System Resources (in the Windows sense of the phrase) could only
: be stored in the first 1MB of memory.

: Is that what you're referring to here? If so, I'm mildly surprised - I would
: have thought the NT5/2k/XP kernels would have gotten past that. Only mildly
: suprised though - it *is* MS we're talking about.

There are enough reason to complain about windows without inventing more.

Win2K is NT, and NT has absolutely nothing to do with DOS based 1meg
limitations.

Purl Gurl () wrote:
: Sherm Pendley wrote:
:
: > Purl Gurl wrote:
:
: > > For NT5, if a typical machine, you are using close
: > > to one-third upwards to one-half of your system
: > > resources simply running your NT5 kernal and Win GUI.
:
: > I haven't used a Windows system in quite some time, but if I recall
: > correctly, System Resources (in the Windows sense of the phrase) could only
: > be stored in the first 1MB of memory.

: You might be thinking of MSDOS lower memory and upper memory,
: LMB and UMB. Gates biggest mistake, decades back, was his decision
: computers would never need more than 640 kilobytes of memory.

DOS was designed (not by Gates) to handle 1 meg, not 640K

It was IBM that placed the hardware at fixed memory locations starting at
the 640K location that created the LMB UMB problems. As for windows 1 meg
system resource memory issues, this was necessary for compatibility with a
lot of software and hardware. The MS solution to these sorts of
limitations was NT, and while NT may have its own problems, you can hardly
say that choosing a different os that does not have the same limitations
is a bad approach to the problem, indeed it is exactly the same strategy
used by everyone who turns to linux and etc to avoid the limitations
within windows.

Purl Gurl wrote:

> There is a Linux machine sitting here, right in there
> with our Windows machines, but I cannot do with Linux
> what I can do with Windows.

Which tells a lot about you and nothing about those machines.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

Purl Gurl wrote:

> Gates made a serious mistake assuming 640 kilobytes
> was plenty of memory to run programs.

At that time it was not a mistake. Predicting the future is hard, and
more silly statements have been made.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

> It is not the number of forked processes. It is the
> amount of system resources used by each forked process.

right.. and resource usage is fine when I get these errors.


> Comparing Linux system resource usage and NT5 system
> resource usage, is not a valid comparison. Linux is
> very minimalist, NT5 is graphics and services rich.

my gnu/linux machine running KDE is just as "graphics and services
rich" as any windows box... I'm not quite sure what you are getting
at.


> You are also comparing threading to forking.

I am comparing the identical piece of code on 2 platforms... even
though it is handled at the OS level differently (forked or emulated
forking via threads).


anyways.... the resolution to my problem was to upgrade the version of
ActiveState Perl I am using. I was using 5.8.2.. i just upgraded to
5.8.4 and I no longer get the memory errors. Now it looks like I can
fork until I run out of resources.

-Corey

Corey_G wrote:

>>It is not the number of forked processes. It is the
>>amount of system resources used by each forked process.
>
> right.. and resource usage is fine when I get these errors.
>
>>Comparing Linux system resource usage and NT5 system
>>resource usage, is not a valid comparison. Linux is
>>very minimalist, NT5 is graphics and services rich.
>
> my gnu/linux machine running KDE is just as "graphics and services
> rich" as any windows box... I'm not quite sure what you are getting
> at.

KDE is not Linux.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

<snip>
>
> For Roberta, I use a classic trick of executing a small
> Visual Basic program, from Perl, which returns data to
> my Windows clipboard. Later, using a Win32 API module,
> my Perl program reads my clipboard, then processes data.
>
> True sequence of events is,
>
> Perl -> dos execution of a visual basic program
> VB -> sends to and reads from a binary dictionary database
> VB -> data to clipboard
> API -> reads clipboard
> Perl -> processes clipboard data
>

Isn't the clipboard a shared resource between processes?
If another program reads or writes to the clipboard, don't
you have the possibility of having the wrong data?
It probably doesn't matter for simple applications.
However, I can't imagine that using the clipboard for
IPC in daemon processes is a good idea.


> For this case, my clipboard is never executed but rather
> data is pushed into the clipboard reserved memory area.
> Perl later reads that memory block via an API call.
> During this, Perl continues to actively process rather
> than waiting for a typical system() call to finish,
> as an example.
>
<snip>
> Purl Gurl