Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 72590 invoked by uid 500); 5 Mar 2002 22:22:45 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 72577 invoked from network); 5 Mar 2002 22:22:45 -0000 Message-ID: <000701c1c494$9888a360$6501a8c0@sashimi> From: "Bill Stoddard" To: "Cliff Woolley" Cc: , "APR Development List" References: Subject: Re: apr_file_open() and caching file descriptors Date: Tue, 5 Mar 2002 17:24:57 -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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Haven't had much time to think about this today, but I did discover that the XTHREAD support in win32 apr_file io is seriously broken. apr_file_open(APR_XTHREAD) on Windows should -not- be creating the overlapped structure and the io completion event. If an open file is being shared across thread, each thread should have it's own instance of apr_file_t with its own instance of the overlapped structure and the completion event. As it is now, if two threads both try to read from a file opened for overlapped i/o at the same time, thread 1 might get the io completion notification for the io issued by thread 2 or visa-versa. Not good. Bill > On Mon, 4 Mar 2002, Bill Stoddard wrote: > > > > apr_file_open(yadda,..., APR_XTHREAD|APR_DO_NOT_REGISTER_CLEANUP, r->pool); > > I don't conceptually have a problem with the APR_NO_CLEANUP flag (or > whatever it would be called), but I do have a problem with using > apr_os_file_get/apr_os_file_put for this. There has got to be a better > way. (For one thing, your APR_XTHREAD flag is meaningless if you do > that.) > > > Rather than an option to not register a cleanup, perhaps a function to > > kill the cleanup would be more generally useful. > > > > apr_file_kill_cleanups(apr_file_t *file); > > You still have a problem with the apr_file_t disappearing when r->pool > goes away, meaning you'd still need the apr_os_file_get/put thing, which > just doesn't seem like a good idea to me. There has got to be a good way > to do this... I'll keep thinking on it and get back to you asap. > > --Cliff > > -------------------------------------------------------------- > Cliff Woolley > cliffwoolley@yahoo.com > Charlottesville, VA > >