Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 63489 invoked by uid 500); 31 Jul 2001 20:42:46 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 63453 invoked from network); 31 Jul 2001 20:42:45 -0000 Errors-To: Message-ID: <0b0f01c11a00$fc9b6890$93c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: "Aaron Bannert" , , "Brad Nicholes" References: <008901c119e7$f1071ec0$8100a8c0@godzilla> <20010731122140.A21458@ebuilt.com> Subject: Re: Conditionals... Date: Tue, 31 Jul 2001 15:39:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N My response below... Brad, what does Netware look like on this? From: "Aaron Bannert" Sent: Tuesday, July 31, 2001 2:21 PM > I've been looking into this over the last few days and although I'm > totally in favor of adding condition variables to APR, I'm not yet > convinced that we can properly implement them on non-POSIX platforms > without some level of kernel support. There is one specific place where > I'm seeing a problem: > > - cond_wait() takes a locked mutex that is associated with the cond. > - it will unlock that mutex and go to sleep > - when it awakens it must immediately reacquire that mutex (awaken() and > acquire() must be a single atomic operation) > - finally, cond_wait() returns. > > Does anyone know of a way around this without some sort of kernel support > to make those two operations atomic? This seems like a serious potential > for race/deadlocks. First, for Win32 syncronization objects, see this chapter http://msdn.microsoft.com/library/en-us/dllproc/hh/winbase/synchro_4q3y.asp?frame=true Second, it _has_ been done on Win32, as redhat's win32 pthreads (lgpl) library shows. What exactly are we trying to accomplish? For this to be truly useful, it has to be abstracted to our non-pthread unix models as well :( If we are just concerned with atomic updates, then we could implement something quite a bit simpler... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/hh/winbase/synchro_925v.asp ...but if we are convinced we want to sleep on the variable, then perhaps we can use the APC Queue to schedule the wakeable async test. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/hh/winbase/synchro_925v.asp I guess I need a pointer to what it is we care to accomplish. It can be done, but to what end? Bill > On Tue, Jul 31, 2001 at 06:39:57PM +0100, David Reid wrote: > > Folks, > > > > The httpd guys have started adding the code that uses pthread conditionals, > > but we did talk about possibly adding it to APR. So, what do we think? > > > > I guess what we're talking about is > > > > apr_cond_t > > > > apr_cond_create > > > > apr_cond_signal > > apr_cond_broadcast > > apr_cond_wait > > > > apr_cond_destroy > > > > I know it'll be a PITA to write the implementation on beos, but it *should* > > be possible. Given that the code in httpd currently is unix specific > > anyway, should we add a cond directory and simply return APR_ENOTIMPL for > > the other platforms while work is started for them? ISTR that no clear > > answer was given as to the possibility of having conditionals on OS/2, > > Windows and Netware... > > > > david > >