Jim Wilcoxson [EMAIL PROTECTED] writes:
4. I saw some notes about rl_returnz (the gzip compression module)
needing to do a different kind of Ns_Return thing to return raw
data. I'm using our standard version and it works fine. Is this
issue particular to the ArsDigita version?
That was me
Jim Wilcoxson wrote:
I'm working again on migrating to 3.x from 2.3.3 and could use some advice.
1. I downloaded the ArsDigita version - 3.3ad13 too. Are there any critical
fixes I need to put in 3.4 before using it for production? Or is 3.3ad13
better for production? Or...?
various
Under 2.3.3, if a scheduled proc did a [ns_thread getid], it got back
a number that corresponded to a Linux process (on Linux, every thread
is a separate process). That isn't the case with 3.4 for scheduled
procs. I don't know what the number is/means.
The AD version has a special SEGV sig
Is every thread a process, or does Linux just implement threads
using a process pool (where each process is responsible for N-number
of threads, where N=1 could be true).
Linux implements threads as light weight processes, so they do tend to
get their own process id (which also mean, I
This isn't a Linux difference - it's an AS difference.
On the same machine, 2.3.3 scheduled procs can do [ns_thread getid] and
will get a number that represents a Linux process, but 3.4 will return
a number that does not represent a Linux process, i.e., there is no
corresponding number in the
