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
Wojciech Kocjan wrote:
Hello.
I've been wondering - is it possible to share filedescriptors and/or
sockets across threads? Both created with open/socket and ns_socket*.
you can't do this in 3.x . you could in 2.x
i hope this appears again in aolserver 4
(if anyone is listening..) it's
On 7 Aug, Mike Hoegeman wrote:
Wojciech Kocjan wrote:
Hello.
I've been wondering - is it possible to share filedescriptors and/or
sockets across threads? Both created with open/socket and ns_socket*.
you can't do this in 3.x . you could in 2.x
i hope this appears again in aolserver 4
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
Patch for ns_urldecode - not decoding + - space:
in nsd/urlencode.c at line 113; broken version:
twobytes[2] = '\0';
while (*string != '\0') {
if (*string != '%') {
Ns_DStringNAppend(pds, string, 1);
++string;
} else {
fixed:
twobytes[2] =
Hi again,
In the adp/tcl docs, there are mentions (ns_mutex for example) of a
command called detach. It doesn't exist, or if it does, it's not called
detach. Can someone shed some light on if a command that does what detach
looks like it's supposed to do exists and if so, what is it?
Would you mind submitting this as a Bug in the SourceForge
Bug Tracker?
http://sf.net/projects/aolserver
-- Dossy
On 2001.08.07, Jim Wilcoxson [EMAIL PROTECTED] wrote:
Patch for ns_urldecode - not decoding + - space:
in nsd/urlencode.c at line 113; broken version:
twobytes[2] = '\0';
Kevin Lawver wrote:
Hi again,
In the adp/tcl docs, there are mentions (ns_mutex for example) of a
command called detach. It doesn't exist, or if it does, it's not called
detach. Can someone shed some light on if a command that does what detach
looks like it's supposed to do exists
On 2001.08.07, Jim Wilcoxson [EMAIL PROTECTED] wrote:
Has anyone ever seen the TCL open command block with TCL 8x? If I use
nsd76, things work fine. With TCL 8x, my startup script hangs at an
open statement, trying to open a file for reading. The only weird thing
is that the file is
Well, sure, but it ain't very interesting:
set fp [open $fn r]
I put an ns_log before it and after it, so I know that's where it's stuck.
I printed $fn - it was fine, although like I said, it is a symbolic link.
Switching from nsd8x to nsd76 fixed it, switching back broke it again.
Jim
13 matches
Mail list logo
