Thanks a lot Perrin for advising to run prefork. I switched to prefork and
I am now able to successfully run apache2 under the debugger/valgrind.
I was finally able to narrow down the problem to symbol clashes between two
shared libraries for which perl bindings were written. Using the right
link
William A. Rowe, Jr. wrote:
>
> http://httpd.apache.org/docs/2.0/mod/quickreference.html
>
> search for the word "stack" and answer your own question
So... testing against worker mpm, the answer is no; ThreadStackSize
is not a supported directive.
Sorry - I'm not often in the internals of prefo
Manoj Bist wrote:
>
> That's why I want to try bumping up the stack size for
> apache/mod_perl. So far I have not been able to find out if that is
> possible in apache2. 0.
Dude - I gave you the answer hours ago
http://httpd.apache.org/docs/2.0/mod/quickreference.html
search for the word "stack
Hi Perrin, Thanks for the response.
I am using threaded MPM.
The self-contained program that I created crashes if I set the stack size to
256K (using ulimit -s). At higher stack size limits it works fine. That's
why I want to try bumping up the stack size for apache/mod_perl. So far I
have not be
On 8/14/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> I'm familiar with copy-on-write. Could you elaborate? From httpd's
> perspective, those same gains are true of worker as well.
Perl's threads don't share much. Most of the memory is used for data
structures, and these are fully dupli
Perrin Harkins wrote:
>
> It definitely could be the cause of issues with a C library using
> sockets that isn't written to be threadsafe. The general reason to
> use prefork though is the more efficient use of memory due to
> copy-on-write.
I'm familiar with copy-on-write. Could you elaborate?
On 8/14/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Few issues here running threaded, but that depends on a host of other
> decisions (ancient library bindings, different host contexts, etc).
It definitely could be the cause of issues with a C library using
sockets that isn't written to
Perrin Harkins wrote:
> On 8/14/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
>> Is it possible to change the stack size in mod_perl(Similar to ulimit -s
>> unlimited etc.)?
>
> The stack size? What are you trying to do? I'm not aware of anything
> special about stack size in mod_perl that would be
On 8/14/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
> Is it possible to change the stack size in mod_perl(Similar to ulimit -s
> unlimited etc.)?
The stack size? What are you trying to do? I'm not aware of anything
special about stack size in mod_perl that would be different from any
other compile
On 8/13/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
> Is there some recommended way to detect if STDOUT is being manipulated?
The source code is usually the easiest way.
> The library is using TCP sockets to communicate with the server.
That usually is not a problem under mod_perl.
> Is there so
Is it possible to change the stack size in mod_perl(Similar to ulimit -s
unlimited etc.)?
Thanks,
Manoj.
On 8/13/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
>
> Hi Perrin,
>
> Is there some recommended way to detect if STDOUT is being manipulated?
> This is what I am doing.
>
> 1. Build a standalo
Hi Perrin,
Is there some recommended way to detect if STDOUT is being manipulated?
This is what I am doing.
1. Build a standalone binary that uses this lib.
2. Run this binary in the debugger and insert breakpoints in read, write,
open and close.
The library is using TCP sockets to communicate w
On 8/13/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
> Thanks for the response. The C library is a third party library which does
> the following:
>
> - Connect to a server running on port 7000 on the local machine.
> - Make an initialize call
> <==This call is consistently
Hi Perrin,
Thanks for the response. The C library is a third party library which does
the following:
- Connect to a server running on port 7000 on the local machine.
- Make an initialize call <==This call is
consistently failing under mod_perl.
- Grab binary data retu
On 8/13/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
> I created a perl binding for a third party "C "library using swig. This
> works fine under CGI but consistently fails under mod_perl.
> Is there a known set of calls(mulithreading etc.) that is not expected to
> work under mod_perl?
Modules with
Hi,
I created a perl binding for a third party "C "library using swig. This
works fine under CGI but consistently fails under mod_perl.
Is there a known set of calls(mulithreading etc.) that is not expected to
work under mod_perl?
I have gone through almost all the mod_perl caveats that I could g
16 matches
Mail list logo
