Thanks, guys - I have a successful build now. If you don't hear from
me again on this then it actually works, too. :)
janine
On Jun 27, 2005, at 10:58 AM, Dossy Shiobara wrote:
On 2005.06.27, Jim Davidson <[EMAIL PROTECTED]> wrote:
Ah -- sorry -- didn't read that far. As for the second erro
On 2005.06.27, Jim Davidson <[EMAIL PROTECTED]> wrote:
> Ah -- sorry -- didn't read that far. As for the second error, the
> problem is the "_np" in "pthread_kill_other_threads_np" which means
> "non-portable". It's an old API in LinuxThreads to kill all threads
> in the process-based threads whi
On 2005.06.27, Janine Sisk <[EMAIL PROTECTED]> wrote:
> Thanks, Jim. Does that include both problems, or just the first one?
> I'm still stuck on the second problem, so any hints would be greatly
> appreciated!
You're referring to this, right:
> I thought I had saved the day, but I ended up stuc
Ah -- sorry -- didn't read that far. As for the second error, the
problem is the "_np" in "pthread_kill_other_threads_np" which means
"non-portable". It's an old API in LinuxThreads to kill all threads
in the process-based threads which pre-date modern Linux kernels.
The fix is to simply remove
Thanks, Jim. Does that include both problems, or just the first one?
I'm still stuck on the second problem, so any hints would be greatly
appreciated!
janine
On Jun 27, 2005, at 5:28 AM, Jim Davidson wrote:
Odd -- I caught this error just last night and fixed. I'll checkin
later today or tom
On 2005.06.27, Bas Scheffers <[EMAIL PROTECTED]> wrote:
> Dossy Shiobara said:
> > This really ought to be a server-wide cache sitting in
> > servPtr->adp.cache rather than itPtr->adp.cache ...
> I would think so! :) The problem with that still is that it is not
> persistent, which could mean that
Odd -- I caught this error just last night and fixed. I'll checkin
later today or tomorrow. I think it's a more strict warning for
gcc4.0 -- the code has technically worked for years :)
-jim
On Jun 26, 2005, at 8:46 PM, Janine Sisk wrote:
I started out with this error:
conn.c: In functio
Dossy Shiobara said:
> This really ought to be a server-wide cache sitting in
> servPtr->adp.cache rather than itPtr->adp.cache ...
I would think so! :) The problem with that still is that it is not
persistent, which could mean that if you restart your server under high
load, all the cache generati
Hi,
The cache is actually a bit complex to follow -- I'll add some
comments to help describe. Basically:
-- Each thread maintains a cache of ADP code which includes per-
interp byte codes and pointers to text regions in a shared area.
When all threads no longer point to the shared text, it's fr
On 2005.06.27, Bas Scheffers <[EMAIL PROTECTED]> wrote:
> This sounds very interesting! Few questions about the cache:
>
> Where does it store the generated pages? Just in memory, or on disk?
In an Ns_Cache named nsadp:$servername:$itPtr, it looks like -- I'm not
sure why it's in a per-interp cach
This sounds very interesting! Few questions about the cache:
Where does it store the generated pages? Just in memory, or on disk?
What is used as "key" for the cached page, the arguments you pass the ADP?
How do you clear the cache?
Cheers,
Bas.
Jim Davidson said:
> Yup -- agreed, default has
11 matches
Mail list logo
