On Sun, 1 Jul 2001 [EMAIL PROTECTED] wrote:
Does this solve the warnings?
If so, please apply.
Two problems:
(1) My system would never get into the elif because I have both SYSVSEM
and FCNTL serialize:
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 0
#define
Yeah, I realized #2 while running. I'll try to log into my solaris box
and fix this tonight.
Ryan
On Sun, 1 Jul 2001, Cliff Woolley wrote:
On Sun, 1 Jul 2001 [EMAIL PROTECTED] wrote:
Does this solve the warnings?
If so, please apply.
Two problems:
(1) My system would never get
Hi,
Yes, the implementation is straightforward, but not how you paint it. It
is actually a lot simpler. I'll present this soon in code. [please be
patient :) ]
I'll present pseudo code here to clarify what I was thinking about.
I'll do the functions first and then explain how it all hangs
Hi,
Yes, the implementation is straightforward, but not how you paint it. It
is actually a lot simpler. I'll present this soon in code. [please be
patient :) ]
I'll present pseudo code here to clarify what I was thinking about.
I'll do the functions first and then explain how it all
On Mon, 2 Jul 2001, Sander Striker wrote:
apr_sms_thread_register(sms, os_thread)
{
[snip]
pms = sms-parent;
while (pms) {
apr_sms_thread_register(os_thread);
pms = pms-parent;
}
[snip]
}
You don't need a while loop here... the recursion ought to take care
On Mon, 2 Jul 2001, Sander Striker wrote:
apr_sms_thread_register(sms, os_thread)
{
[snip]
pms = sms-parent;
while (pms) {
apr_sms_thread_register(os_thread);
pms = pms-parent;
}
[snip]
}
You don't need a while loop here... the recursion ought to
APR seems to be missing the O_NONBLOCK flag to apr_file_open. This
means that calls to open on named pipes will block until the producer
has opened the pipe for writing. Is this intended? I have no idea
how this works on win32, but a patch for unix is attached..
-Ryan
Index:
I think with the testmem and Ian's testpool, I think we are close to
having a decent testing environment that is outside of the real
world. The only thing I'm waiting on now is David's implementation of
apr_pool_t as a SMS. =)
OK, OK, it's on it's way :) Patience is a virtue!
We
On Sunday, July 1, 2001, at 06:46 AM, Pier P. Fumagalli wrote:
Aaron Bannert at [EMAIL PROTECTED] wrote:
On Sat, Jun 30, 2001 at 02:53:44AM +0100, Pier P. Fumagalli wrote:
On Darwin 1.3.7 I had an error building locks/unix/crossproc.c
What was the error? Maybe autoconf is incorrectly detecting
Disabling SYSV semaphores lets the build continue. It breaks later in
apr_sms_trivial.c, but that looks easy to fix.
I tested it on my box and it all runs fine. What seems to be the
problem?
Chuck Murcko
Sander
[EMAIL PROTECTED] writes:
trawick 01/07/02 04:56:23
Modified:.CHANGES
user/unix userinfo.c
Log:
Handle the weird case where getpwnam() returns NULL but errno is zero.
This led to a segfault on apache.org when apache did a home directory
lookup
Justin Erenkrantz [EMAIL PROTECTED] writes:
Can someone enlighten me as to why we have --with-pthread-cross and we
aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
and pthread_mutexattr_setpshared, it seems reasonable enough to
define USE_PROC_PTHREAD_SERIALIZE to 1.
(meant to follow up on the list... darn!)
---BeginMessage---
Cliff Woolley [EMAIL PROTECTED] writes:
Just a heads up on some warnings I'm getting on Solaris 2.6 where
APR_USE_PROC_PTHREAD_SERIALIZE is selected:
locks.c: In function `apr_os_lock_get':
locks.c:344: warning: assignment makes
Hmmm... looks like we don't wrap something with #elif as required.
I dn't have access to a Solaris box, but I'll take a gander.
Cliff Woolley wrote:
Just a heads up on some warnings I'm getting on Solaris 2.6 where
APR_USE_PROC_PTHREAD_SERIALIZE is selected:
locks.c: In function
On 2 Jul 2001, Jeff Trawick wrote:
struct apr_os_lock_t {
#if APR_HAS_PROC_PTHREAD_SERIALIZE
pthread_mutex_t *pthread_crossproc; /* NULL if not used */
#endif
#if APR_HAS_SYSVSEM_SERIALIZE || APR_HAS_FCNTL_SERIALIZE ||
APR_HAS_FLOCK_SERIALIZE
int int_crossproc; /*
We actually removed that option specifically because it wasn't portable.
:-( I think this will fall out in the wash with the named pipe redesign
however. If the namedpipe_create function returns a handle to the pipe,
then we can be sure to open that handle as a nonblocking operation.
Ryan
On
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Mon, Jul 02, 2001 at 08:21:10AM -0400, Jeff Trawick wrote:
Please don't commit just yet.
Should I back this out? Ryan wants to TR at 10AM PST. I guess the
easy fix would be to place fcntl() decision AFTER the
pthread_mutex_t support.
On Mon, Jul 02, 2001 at 04:23:49PM -, [EMAIL PROTECTED] wrote:
jerenkrantz01/07/02 09:23:49
Modified:.configure.in
Log:
fcntl() should be our preference for the short-term.
Our support of pthread_mutex_t needs more work before we can make it
the default (if
On Mon, Jul 02, 2001 at 09:38:37AM -0700, Ian Holsman wrote:
Just wondering if any has got one of these going,
how does the proposed SMS shared library handle pointers?
Can you please expand a bit further on what you mean?
Oh, do you mean, How does the proposed SMS shared memory system
On Mon, Jul 02, 2001 at 09:38:37AM -0700, Ian Holsman wrote:
Just wondering if any has got one of these going,
how does the proposed SMS shared library handle pointers?
Can you please expand a bit further on what you mean?
Oh, do you mean, How does the proposed SMS shared memory
[...]
Thanks! If I understand this correctly, the only place where the thread
registration logic is invoked automatically is in thread creation, right?
Yes.
Coupling the registration to thread creation, rather than SMS creation,
resolves some of the concerns that I listed previously. But I
+1. Makes the code so much easier to understand. -- justin
On Mon, Jul 02, 2001 at 11:30:59AM -0700, Aaron Bannert wrote:
As discussed earlier on new-httpd and [EMAIL PROTECTED], the lock scope
CROSS_PROCESS is not portable, where LOCKALL is. I've fixed
that by simply removing CROSS_PROCESS.
stoddard01/07/01 08:13:35
Modified:network_io/win32 sendrecv.c
Log:
Back out this portion of Bill Rowe's large file support patch. We should
not
use the event handle in the apr_file_t to do overlapped i/o on a socket. We
either need to wait for io completion on the
Sander Striker wrote:
[...]
Coupling the registration to thread creation, rather than SMS creation,
resolves some of the concerns that I listed previously. But I still have
some questions about what happens during alloc/free in this model.
Is your plan that the alloc/free functions should
[...]
The child thread is register in the parent thread. So, in the case of
the first created thread, a lock will be created. This does not happen
in the stub.
That eliminates the first race condition, but not the second.
Consider this
usage:
* There are two global SMSs, sms1 and sms2.
25 matches
Mail list logo
