Planejamento Estrat�gico
Planejamento Estratégico & Empresarial Caxias do Sul 1/out (sexta) Local: Parthenon Caxias do Sul Rua Os Dezoito do Forte, 1934, Centro, Caxias do Sul, RS São Paulo 15/out (sexta) Local: Alameda Santos,1909/1897 - 11º andar, São Paulo (Clique aqui e veja o mapa) Campinas (UNICAMP) 25/out (segunda) Local: Campus UNICAMP s/número Barão Geraldo, Campinas, SP (Clique aqui e veja o mapa) Objetivo: Demonstrar como fazer do processo de planejamento anual uma tarefa integrada, com ganho de qualidade e compromisso de toda a equipe. Público-alvo: Todos os profissionais envolvidos com o processo orçamentário na empresa, especialmente Diretores e Gerentes de Vendas, Marketing, Produção e Controladoria. 1. Planejamento Estratégico • Mercado Total, Disponível, Alvo • Processo e Metodologia (Análise SWOT) • Plano A, Plano B, etc... • Conceito e Aplicação de Balanced Scorecard • Gestão por Projetos (Estratégia Aplicada). 2. Estratégia de Mercado • Marketing Estratégico x Gestão Comercial • Produtos Velhos e Novos • Níveis de Preço x Valor Percebido • Estratégia de Preço e Lucro • Organização de Vendas • Territórios, Canais, Key Accounts, etc... 3. Planejamento Integrado de Lucro • Volume, Preço e Custos Operacionais • Ponto de Equilíbrio • Modelagem Estratégica (Mercado X Margem) • Planilhas de Projeção (Receitas, Custos e Lucro Operacional) • Valor da Empresa (Metodologia Internacional de Cálculo) Investimento: R$ 360 O preço inclui: CD com o material apresentado, kit para exercícios e certificado. Recomendamos trazer calculadora. Serão servidos dois coffee-breaks, o intervalo do almoço é livre. Inscreva-se on-line em www.ipge.com.br ou ligue (11) 5505-1968 das 9 às 17 hs Clique aqui para ver a lista de Empresas que já realizaram nossos cursos. Outros cursos em São Paulo: * Preço e Custo para decisão Comercial - 21/09 * Básico de Vendas - Produtos e Serviços - 22/09 * Administração de Vendas (Organização, Clientes e Equipes) - 23/09 Lista completa de cursos em www.ipge.com.br Gestão Estratégica nas Pequenas e Médias Empresas Está fora de São Paulo? Faça nossos cursos online! Clique aqui para ler mais... Para REMOVER ou INCLUIR seu e-mail deste informativo a qualquer momento visite nosso website (clique aqui).
Re: Break Up each Poll Implmentation
Sigh. I forgot to update the patch file with the updated header... Just need to move the POLL_USES_* stuff down to its own if/else.. @@ -46,16 +46,21 @@ #define HAS_PIPES(dt) (dt == APR_POLL_FILE) ? 1 : 0 #endif -/* Choose the best method platform specific to use in apr_pollset */ +/* Choose the best platform specific method to use in apr_pollset_* */ #ifdef HAVE_KQUEUE #define POLLSET_USES_KQUEUE #elif defined(HAVE_EPOLL) #define POLLSET_USES_EPOLL #elif defined(HAVE_POLL) #define POLLSET_USES_POLL -#define POLL_USES_POLL #else #define POLLSET_USES_SELECT +#endif + +/* Choose the best platform specific method to use in apr_poll() */ +#ifdef HAVE_POLL +#define POLL_USES_POLL +#else #define POLL_USES_SELECT #endif -Paul
Re: Break Up each Poll Implmentation
On Thu, Sep 23, 2004 at 01:04:10PM -0600, Paul Querna wrote: > Builds and works on Linux and OS-X. I am pretty sure it breaks the > build system on Netware and Windows. > > Are there any objections to breaking up this file into one for each > implementations? I think this is a good idea, though I would do s/poll_// on the new filenames since they already have a 'poll/' prefix... joe
Break Up each Poll Implmentation
Attached is a patch that moves each Poll & Pollset implementation into
their own file.
This does not include any changes in my previous patch. This only moves
the existing code as it is in CVS to different files. There are no code
changes. Just removing of lots of #ifdefs and renaming some of the
defines.
Added Files:
include/arch/unix/apr_arch_poll_private.h
poll/unix/poll_epoll.c
poll/unix/poll_kqueue.c
poll/unix/poll_poll.c
poll/unix/poll_select.c
Removed:
poll/unix/poll.c
Builds and works on Linux and OS-X. I am pretty sure it breaks the
build system on Netware and Windows.
Are there any objections to breaking up this file into one for each
implementations?
The code was becoming impossible to read with some many different
defines. I believe the minimal amount of code that is now shared
between each file is acceptable, compared to the previous ifdef hell.
-Paul Querna
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ poll/unix/poll_poll.c 2004-09-23 11:25:32.740663202 -0700
@@ -0,0 +1,259 @@
+/* Copyright 2000-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "apr_arch_poll_private.h"
+
+#if defined(POLL_USES_POLL) || defined(POLLSET_USES_POLL)
+
+static apr_int16_t get_event(apr_int16_t event)
+{
+apr_int16_t rv = 0;
+
+if (event & APR_POLLIN)
+rv |= POLLIN;
+if (event & APR_POLLPRI)
+rv |= POLLPRI;
+if (event & APR_POLLOUT)
+rv |= POLLOUT;
+if (event & APR_POLLERR)
+rv |= POLLERR;
+if (event & APR_POLLHUP)
+rv |= POLLHUP;
+if (event & APR_POLLNVAL)
+rv |= POLLNVAL;
+
+return rv;
+}
+
+static apr_int16_t get_revent(apr_int16_t event)
+{
+apr_int16_t rv = 0;
+
+if (event & POLLIN)
+rv |= APR_POLLIN;
+if (event & POLLPRI)
+rv |= APR_POLLPRI;
+if (event & POLLOUT)
+rv |= APR_POLLOUT;
+if (event & POLLERR)
+rv |= APR_POLLERR;
+if (event & POLLHUP)
+rv |= APR_POLLHUP;
+if (event & POLLNVAL)
+rv |= APR_POLLNVAL;
+
+return rv;
+}
+
+#endif /* POLL_USES_POLL || POLLSET_USES_POLL */
+
+
+#ifdef POLL_USES_POLL
+
+#define SMALL_POLLSET_LIMIT 8
+
+APR_DECLARE(apr_status_t) apr_poll(apr_pollfd_t * aprset, apr_int32_t num,
+ apr_int32_t * nsds,
+ apr_interval_time_t timeout)
+{
+int i, num_to_poll;
+#ifdef HAVE_VLA
+/* XXX: I trust that this is a segv when insufficient stack exists? */
+struct pollfd pollset[num];
+#elif defined(HAVE_ALLOCA)
+struct pollfd *pollset = alloca(sizeof(struct pollfd) * num);
+if (!pollset)
+return APR_ENOMEM;
+#else
+struct pollfd tmp_pollset[SMALL_POLLSET_LIMIT];
+struct pollfd *pollset;
+
+if (num <= SMALL_POLLSET_LIMIT) {
+pollset = tmp_pollset;
+}
+else {
+/* This does require O(n) to copy the descriptors to the internal
+ * mapping.
+ */
+pollset = malloc(sizeof(struct pollfd) * num);
+/* The other option is adding an apr_pool_abort() fn to invoke
+ * the pool's out of memory handler
+ */
+if (!pollset)
+return APR_ENOMEM;
+}
+#endif
+for (i = 0; i < num; i++) {
+if (aprset[i].desc_type == APR_POLL_SOCKET) {
+pollset[i].fd = aprset[i].desc.s->socketdes;
+}
+else if (aprset[i].desc_type == APR_POLL_FILE) {
+pollset[i].fd = aprset[i].desc.f->filedes;
+}
+else {
+break;
+}
+pollset[i].events = get_event(aprset[i].reqevents);
+}
+num_to_poll = i;
+
+if (timeout > 0) {
+timeout /= 1000;/* convert microseconds to milliseconds */
+}
+
+i = poll(pollset, num_to_poll, timeout);
+(*nsds) = i;
+
+for (i = 0; i < num; i++) {
+aprset[i].rtnevents = get_revent(pollset[i].revents);
+}
+
+#if !defined(HAVE_VLA) && !defined(HAVE_ALLOCA)
+if (num > SMALL_POLLSET_LIMIT) {
+free(pollset);
+}
+#endif
+
+if ((*nsds) < 0) {
+return apr_get_netos_error();
+}
+if ((*nsds) == 0) {
+return APR_TIMEUP;
+}
+return APR_SUCCESS;
+}
+
+
+#endif /* POLL_USES_POLL */
+
+
+#ifdef POLLSET_USES_POLL
+
+struct apr_pollset_t
+{
+apr_pool_t *pool;
+apr_uint32_t nelts;
+apr_uint32_t nalloc;
+struct pollfd *pollset;
+apr_pollfd_t *query_set;
+apr_pollfd_t *result_set
Broken links
Hi. Some of the links to the different module documentation are broken on this page: http://apr.apache.org/docs/apr/modules.html All of the module links are broken on this page: http://apr.apache.org/docs/apr-util/modules.html -- Jason
Re: apr compiling errors
any other ideas? gcc seems to be working for all my other apps..yesterday i just compiled bdb for something else and it didn't complain about ld or gcc On Sep22, 14:35, Mark wrote: > On Sep22, 22:00, Joe Orton wrote: > > On Wed, Sep 22, 2004 at 09:30:15PM +0100, Joe Orton wrote: > > > On Wed, Sep 22, 2004 at 12:32:29PM -0700, Mark wrote: > > > > checking for MAP_ANON in sys/mman.h... yes > > > > checking for /dev/zero... yes > > > > ./configure:Error: decision on anonymous shared memory allocation > > > > method failed > > > > > > If you are using apr from an httpd tarball, then what version? Please > > > upload the config.log somewhere so we can have a look at it. > > > > The config.log Mark sent me had: > > > > configure:16382: checking for mmap > > configure:16432: gcc -o conftest -g -O2 -pthreads -DSOLARIS2=8 > > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT conftest.c -lm > > +-lsocket -lns > > l -lresolv -lpthread >&5 > > collect2: ld terminated with signal 11 [Segmentation Fault], core dumped > > configure:16435: $? = 1 > > > > is there a reason you passed --with-gnu-ld to configure? I'd try it > > without. Otherwise, it looks like you have a broken GCC installation. > > Can you compile simple programs with it? > > > > joe > > i tried without the tag as well..but didnt work > > gcc does compile other programs without problems..
Re: [OT] Developer lists and Reply-To header
On Thu, 23 Sep 2004, Mladen Turk wrote: > I found myself couple of times replying to the original sender > by default, while my intention was to reply to the list. > The solution is either to 'reply to all' (why would anyone > wish to receive two messages about the same subject?) or doing > that by hand. We all just reply-to-all typically. We've gone back and forth about this many times in the past and I suppose just ended up deciding that most of us preferred it this way rather than the other way. Shrug. --Cliff
RE: Pollset: Thread Safe & More
Just to chime in, I had to implement something similar to what Joe suggested to solve the problem. An add queue and a delete queue in addition I had to create a method for poking the select to wake up and cycle through the additions and subtractions. Since most of the additions and subtractions were on either a close or an accept, the poking of the Q was really only need when I wanted to add the APR_POLLOUT event to the select. In my experience adding and removing events happens quite often in all socket programs. It would be extremely useful if this functionality was built into the apr and was thread safe. Don't the pools use mutexing already, is this platform specific? -Original Message- From: Paul Querna [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 11:09 AM To: Joe Orton Cc: dev@apr.apache.org Subject: Re: Pollset: Thread Safe & More On Thu, 2004-09-23 at 11:38 +0100, Joe Orton wrote: > So I'm worried this patch is really solving the problem in the wrong > place. The thing you are exporting here in the APR API, "is the > apr_pollset_* interface thread-safe in _add and _remove", seems really > horrible. Either an API is thread-safe, or it isn't. Making that a > *per-platform* flag seems like really bad design. I agree with your conclusion here. It isn't a good design to have platform specific properties like thread safety. Part of my goal was to avoid using KQueue/EPoll directly in the Event MPM, and to keep it using the APR Generic Functions. I think that I will just make an ap_ex_pollset_* set of functions to wrap EPoll/KQueue and include them directly in the Event MPM. -Paul Querna © 2004 OpenLink Financial Copyright in this message and any attachments remains with us. It is confidential and may be legally privileged. If this message is not intended for you it must not be read, copied or used by you or disclosed to anyone else. Please advise the sender immediately if you have received this message in error. Although this message and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Open Link Financial, Inc. for any loss or damage in any way arising from its use.
Re: Pollset: Thread Safe & More
On Thu, Sep 23, 2004 at 09:08:59AM -0600, Paul Querna wrote: > On Thu, 2004-09-23 at 11:38 +0100, Joe Orton wrote: > > So I'm worried this patch is really solving the problem in the wrong > > place. The thing you are exporting here in the APR API, "is the > > apr_pollset_* interface thread-safe in _add and _remove", seems really > > horrible. Either an API is thread-safe, or it isn't. Making that a > > *per-platform* flag seems like really bad design. > > I agree with your conclusion here. It isn't a good design to have > platform specific properties like thread safety. I suppose it wouldn't be so bad if this was enabled as flag passed to apr_pollset_create (which already has a convenient flags parameter, kudos to whomever for the forward thinking there). apr_pollset_create(,,,APR_POLLSET_THREADSAFE) which gives ENOTIMPL for non-kqueue/epoll implementations, and the mutex locking is only used if it *is* specified. > Part of my goal was to avoid using KQueue/EPoll directly in the Event > MPM, and to keep it using the APR Generic Functions. I think that I > will just make an ap_ex_pollset_* set of functions to wrap EPoll/KQueue > and include them directly in the Event MPM. It does seem a shame to duplicate so much of this stuff... joe
Re: Pollset: Thread Safe & More
On Thu, 2004-09-23 at 11:38 +0100, Joe Orton wrote: > So I'm worried this patch is really solving the problem in the wrong > place. The thing you are exporting here in the APR API, "is the > apr_pollset_* interface thread-safe in _add and _remove", seems really > horrible. Either an API is thread-safe, or it isn't. Making that a > *per-platform* flag seems like really bad design. I agree with your conclusion here. It isn't a good design to have platform specific properties like thread safety. Part of my goal was to avoid using KQueue/EPoll directly in the Event MPM, and to keep it using the APR Generic Functions. I think that I will just make an ap_ex_pollset_* set of functions to wrap EPoll/KQueue and include them directly in the Event MPM. -Paul Querna
Re: [PATCH] Add BDB 4.3 support to the apr-util/build/dbm.m4
On 2004-09-23 13:26+0100, Joe Orton wrote:
> On Tue, Sep 21, 2004 at 07:59:19PM -0600, Jani Averbach wrote:
> > This patch adds support for 'sometime in the future to be released'
> > Berkeley DB 4.3.
>
> a.k.a. make apr-util/configure another three times slower :)
>
No comments. =)
> Thanks Jani, committed to HEAD, I guess it applies the same to 0.9.x and
> should be done there too...
There is one little difference:
0.9.x:
APU_CHECK_BERKELEY_DB("4", "1", "-1",
"$places",
"db41/db.h db4/db.h db.h",
"db-4.1 db4 db"
)
...
APU_CHECK_BERKELEY_DB("4", "2", "-1",
"$places",
"db42/db.h db4/db.h db.h",
"db-4.2 db4 db"
)
When 1.0.x uses:
APU_CHECK_BERKELEY_DB("4", "1", "-1",
"$places",
"db41/db.h db4/db.h db.h",
"db-4.1 db41 db4 db"
)
...
APU_CHECK_BERKELEY_DB("4", "2", "-1",
"$places",
"db42/db.h db4/db.h db.h",
"db-4.2 db42 db4 db"
)
I don't know why there is this difference. So, if it was there by
intention, then the patch should be changed to use:
APU_CHECK_BERKELEY_DB("4", "3", "-1",
"$places",
"db43/db.h db4/db.h db.h",
"db-4.3 db4 db"
)
if not, perhaps we should haul the whole file from 1.0.x to the 0.9.x?
*shrug*
BR, Jani
--
Jani Averbach
Re: Pollset: Thread Safe & More
On Thu, 2004-09-23 at 11:38 +0100, Joe Orton wrote: > On Wed, Sep 22, 2004 at 08:57:24PM -0600, Paul Querna wrote: > > Attached is a Patch for apr_pollset_*. > > Changes Include: > > - Replace HAS_* with USE_* to remove some complex #ifdef stuff. > > - Partially thread safe (*) > > - Removes the limitation on the number of sockets that you can add to a > > pollset (**) > > This is kind of neat. But :) > > w.r.t thread-safety: Pushing this stuff down into the APR pollset code > means that all non-threaded users of the pollset API incur extra > overhead for functionality which they don't need or care about. > > In the event MPM, could you not, for instance, just keep two queues of > "pollfds to remove" and "pollfds to add" which are handled with > appropriate locking, and then process these queues calling _add and > _remove appropriate after _poll() returns? i.e. ensure that a single > thread owns the pollset structure. That is sort of the previous design. The problem is, we don't know how long a thread will be stuck inside the _poll(). It could be a tiny amount of time in a busy server, but on a server w/ only one client connection, it might take 10 seconds or some such to leave a _poll(). The primary reason I pushed it down lower to APR is that both KQueue and EPoll support 'adding while polling'. That is, Thread A can be inside a _poll() and other threads can safely add an FD to the query set. That FD will show up in the result set without any other magic. (not possible with traditional poll/select). > w.r.t. unlimited size of pollset: this could be solved in a general > manner, for *all* implementations, by adding an apr_pollset_resize() > call. I thought about doing a _resize function originally. To safely resize, you would need to lock everything out first. Since there isn't really a realloc type function for pools, you would end up palloc`ing new arrays and copying the data. This seems really bad to me on a busy server. It does not seem very realistic or efficient to basically pause a busy server and copy 20,000 FDs over to an array that is bigger. > So I'm worried this patch is really solving the problem in the wrong > place. The thing you are exporting here in the APR API, "is the > apr_pollset_* interface thread-safe in _add and _remove", seems really > horrible. Either an API is thread-safe, or it isn't. Making that a > *per-platform* flag seems like really bad design. > Perhaps. First thing I am going to do is break up the current code in CVS into multiple files. I am really starting to dislike all these ifdefs in the current implementation. I think this should be done regardless of this patch. -Paul Querna
Re: [OT] Developer lists and Reply-To header
Greg Marr wrote: Is there any reason why apr, apr-util, httpd mailing lists have Reply-To header set to the sender and not to the list itself. Search for reply-to considered harmful on Google and you'll find more information than you ever wanted to read about both sides of the issue. If you meant the article by Chip Rosenthal it didn't convince me. It's just a personal opinion about his favorite emailer (elm). The big question is which is worse, sending a message to the list when your intention was to send it to a single person. The worse is as is where httpd list mailer actually does add Reply-To header, while apr's does not. Also almost any other ASF hosted mailing list (that I'm member of) sets that header. As a poster I don't expect to receive a separate mail 'CC-ed' to me personally if it's already posted on the list as an reply, and that is quite often, cause (myself too) people just hit 'reply to all'. Anyhow, the subject starts with [OT], so it's not such a big deal thought :). Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] Add BDB 4.3 support to the apr-util/build/dbm.m4
On Tue, Sep 21, 2004 at 07:59:19PM -0600, Jani Averbach wrote: > This patch adds support for 'sometime in the future to be released' > Berkeley DB 4.3. a.k.a. make apr-util/configure another three times slower :) Thanks Jani, committed to HEAD, I guess it applies the same to 0.9.x and should be done there too... joe
Re: [OT] Developer lists and Reply-To header
At 07:20 AM 9/23/2004, Mladen Turk wrote: Is there any reason why apr, apr-util, httpd mailing lists have Reply-To header set to the sender and not to the list itself. I think almost all other lists has the 'Replay-To' header set to the list itself. I mean, I'm receiving the messages from the list and not from the particular poster, so I should reply to the list, right? Search for reply-to considered harmful on Google and you'll find more information than you ever wanted to read about both sides of the issue. I found myself couple of times replying to the original sender by default, while my intention was to reply to the list. The solution is either to 'reply to all' (why would anyone wish to receive two messages about the same subject?) or doing that by hand. The big question is which is worse, sending a message to the list when your intention was to send it to a single person, sending a message to a single person when your intention was to send it to the list. You'll find large numbers of people on each side. Some mailing list software is smart enough to not send an extra copy to members that will be receiving it directly.
[OT] Developer lists and Reply-To header
Hi, Is there any reason why apr, apr-util, httpd mailing lists have Reply-To header set to the sender and not to the list itself. I think almost all other lists has the 'Replay-To' header set to the list itself. I mean, I'm receiving the messages from the list and not from the particular poster, so I should reply to the list, right? I found myself couple of times replying to the original sender by default, while my intention was to reply to the list. The solution is either to 'reply to all' (why would anyone wish to receive two messages about the same subject?) or doing that by hand. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: Pollset: Thread Safe & More
On Wed, Sep 22, 2004 at 08:57:24PM -0600, Paul Querna wrote: > Attached is a Patch for apr_pollset_*. > Changes Include: > - Replace HAS_* with USE_* to remove some complex #ifdef stuff. > - Partially thread safe (*) > - Removes the limitation on the number of sockets that you can add to a > pollset (**) This is kind of neat. But :) w.r.t thread-safety: Pushing this stuff down into the APR pollset code means that all non-threaded users of the pollset API incur extra overhead for functionality which they don't need or care about. In the event MPM, could you not, for instance, just keep two queues of "pollfds to remove" and "pollfds to add" which are handled with appropriate locking, and then process these queues calling _add and _remove appropriate after _poll() returns? i.e. ensure that a single thread owns the pollset structure. w.r.t. unlimited size of pollset: this could be solved in a general manner, for *all* implementations, by adding an apr_pollset_resize() call. So I'm worried this patch is really solving the problem in the wrong place. The thing you are exporting here in the APR API, "is the apr_pollset_* interface thread-safe in _add and _remove", seems really horrible. Either an API is thread-safe, or it isn't. Making that a *per-platform* flag seems like really bad design. joe
Re: cvs commit: apr/threadproc/win32 thread.c
On 23 Sep 2004 06:17:59 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> mturk 2004/09/22 23:17:59
>
> Modified:threadproc/win32 Tag: APR_0_9_BRANCH thread.c
> Log:
> Backport from HEAD.
> Makes the threads to behave like on posix. If the thread is created without
> APR_DETACH expect that the thread_join will be called, so don't close the
> handle in advance, if the thread has already finished.
> Reviewed by: wrowe
you've got some isolated CR characters in your commit that need to be
cleaned up; here is one example:
if ((*new) == NULL) {
return APR_ENOMEM;
}
(*new)->pool = pool;
(*new)->detach = 0;^M <--
return APR_SUCCESS;
}
also, if committing CHANGES separately from thread.c was intentional,
please try to commit them together in the future so that the related
change appears in the same commit log
if you have a broken cvs client which fails to commit files in the
current directory if there are other files to commit as well, you can
change to .. and do a commit on (for example) "apr/CHANGES
apr/threadproc/win32/thread.c" to work around the bogosity
[STATUS] (apr-util) Wed Sep 22 23:45:24 EDT 2004
APRUTIL LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2004/06/30 11:44:19 $] Release: 1.0.0 rc2 : Tagged June 30th 2004(APU_1_0_RC2) 1.0.0 rc1 : Tagged June 2004 (APU_1_0_RC1) 0.9.3 : Tagged March 30, 2002 0.9.2 : Released March 22, 2002 (alpha) 0.9.1 : Released September 11, 2002 (alpha) 0.9.0 : Not released 2.0a9 : released December 12, 2000 RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Solaris's Sun Freeware (sfw) package has a busted gcc/ld setup. This gcc passes -L/opt/sfw/lib to /usr/ccs/bin/ld, but does not pass -R. Therefore, when trying to run the code using a library from /opt/sfw/lib (say, libdb), the run-time linker will not look in /opt/sfw/lib and the program will die. Status: Workaround is to add "-R/opt/sfw/lib" to LDFLAGS. Should check latest sfw package set and see if Sun may have fixed this. * GDBM usage of errno is not-thread-safe. Fix. Other bugs that need fixing: Other features that need writing: * possibly move test/testdbm* to util/dbu Justin says: Do we still want to do this? testdate is now in test. Status: Greg +1 (volunteers) Documentation that needs writing: * API documentation Status: * doc the lifetimes of apr_dbm return values Available Patches: Open Issues:
[STATUS] (apr) Wed Sep 22 23:45:17 EDT 2004
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2004/09/02 03:49:03 $] Releases: Standalone 1.0.0 : released September 1, 2004 0.9.3 : tagged March 30, 2003 0.9.2 : released March 22, 2003 0.9.1 : released September 11, 2002 0.9.0 : released August 28, 2002 Bundled with httpd 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE 0.9 SHOWSTOPPERS: RELEASE 1.0 SHOWSTOPPERS: CURRENT VOTES: CURRENT test/testall -v EXCEPTIONS: Please add any platform anomilies to the following exception list. * various tests fail on Unix in VPATH builds. * 'testipsub' will tickle an Solaris 8 getaddrinfo() IPv6 bug, causing the test to hang. Configure with --disable-ipv6 if using an unpatched Solaris 8 installation. * The 'testdso' tests will not work if configured with --disable-shared since the loadable modules cannot be built. * 'testdso' fails on older versions of OpenBSD due to dlsym(NULL, ...) segfaulting. * BUG: Win32 fails test in File Info: test_stat_eq_finfo apr_stat and apr_getfileinfo differ in protection ... wrowe guesses that we are checking the handle objects' permissions rather than the filesystem objects' permissions. * Win32 Not Implemented tests Pipes: set_timeout/read_write; can't timeout blocking pipes Socket Creation: tcp6_socket and udp6_socket (at least by default) Socket Options: corkable: TCP isn't corkable Users: username: Groups from apr_uid_get not implemented RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Someone needs to port testucs to Unix. Right now it only works on Windows. * The return type of a thread function (void *) is inconsistent with the type used in apr_thread_exit()/apr_thread_join() (apr_status_t). The thread function's return type should be changed to apr_status_t so that a return from the thread main function has the same effect as apr_thread_exit(). See Message-Id: <[EMAIL PROTECTED]> for thread discussing this. +1: BrianH, Aaron, david, jerenkrantz Status: Will Rowe was working on this. * Need some architecture/OS specific versions of the atomic operations. progress: generic, solaris Sparc, FreeBSD5, linux, and OS/390 done need: AIX, AS400, HPUX * The new lock API is a full replacement for the old API, but is not yet complete on all platforms. Components that are incomplete or missing include: Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?) * proc_mutex is not necessary on NetWare since the OS does not support processes. The proc_mutex APIs actually redirect to the thread_mutex APIs. (bnicholes) OS/2: apr_thread_cond_*(), apr_proc_mutex_*() Less critical components that we may wish to add at some point: Beos: apr_thread_rwlock_try*lock() apr_proc_mutex_trylock() Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread Win32: apr_thread_cond_timedwait(), apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?) * Need to contemplate apr_strftime... platforms vary. OtherBill suggested this solution (but has no time to implement): Document our list of 'supported' escapes. Run some autoconf/m4 magic against the complete list we support. Move the strftime re-implementation from time/win32 to time/unix. Add some APR_HAVE_STRFTIME magic to use the system fn, or fail over to time/unix/strftime.c. Message-ID: <[EMAIL PROTECTED]> * Using reentrant libraries with non-threaded APR - Anecdotal evidence exists that suggests it is bad to mix reentrant and non-reentrant libraries and therefore we should always use the reentrant versions. - Unfortunately, on some platforms (AIX 4.2.1) defining the reentrant flag (-D_THREAD_SAFE) causes builds to fail, and so one would expect --disable-threads to fix this. Although this has been fixed for that particular version of AIX, it may be useful to only enable the reentrant versions when threads are enabled. How will we deal with this issue once APR becomes a standalone library? It is perfectly legitimate to have apps needing both versions (threaded/reentrant and non-threaded/non-reentrant) on the same machine. * Pools debugging - Find a way to do check if a pool is u
Pollset: Thread Safe & More
Attached is a Patch for apr_pollset_*.
Changes Include:
- Replace HAS_* with USE_* to remove some complex #ifdef stuff.
- Partially thread safe (*)
- Removes the limitation on the number of sockets that you can add to a
pollset (**)
* The patch allows multiple threads to concurrently call _add() or
_remove(). It is still only safe for one thread to call _poll() at a
time. This is only for EPoll and KQueue.
** It will still only return the the maximum number of pollfds you
declared in _create() to any single _poll() call. (pollset->nalloc).
This is only for EPoll and KQueue.
The patch removes the query_set array, and instead uses a set of 3
APR_RINGs to manage the pollfds:
query_ring - pollfds that are in active use.
dead_ring - pollfds that need to be free`ed after the next _poll()
free_ring - pollfds that we are free to reuse
in _add():
- If there is an extra pollfd in the free_ring, reuse it.
- If not, palloc() one.
in _remove():
- Move the pollfd from the query_ring to the dead_ring
in _poll():
- After polling is complete, move any pollfds inside the dead_ring to
the free_ring, as it is safe to re-use them now.
I would like to use these changes in the 'event' MPM for httpd.
My primary motivations for the pollset changes where:
- Not acceptable for an _add() to fail because the query_set array was
too small.
- Not acceptable to have to do high level locking of the different
pollset functions.
With these changes, 'Worker' threads can _add a socket directly back
into the Event Threads pollset, without having to wake it the Event
Thread, or preform any extra locking.
I have tested these changed on both 2.6 Linux (EPoll) and Mac OS X
10.3.5 (KQueue).
Currently, the file poll.c has turned into an "#ifdef' hell. In the
near future, I would like to break out the current poll.c file into
multiple files, one for each major implementation, eg:
pollset_epoll.c
pollset_kqueue.c
pollset_select.c
pollset_poll.c
If there are no objects to breaking it up into multiple files, I will
take a swing at it this weekend.
I almost consider the Current Patch to be un-reviewable, because of all
the things I had to change. If I can break pollset into multiple files,
hopefully, I can make a much more reviewable patch. :)
A word of thanks to Rici Lake for helping me debug these changes via
IRC.
As always, comments are very welcome.
-Paul Querna
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.597
diff -u -r1.597 configure.in
--- configure.in 1 Aug 2004 00:52:20 - 1.597
+++ configure.in 23 Sep 2004 02:09:52 -
@@ -633,7 +633,8 @@
AC_SUBST(have_sigsuspend)
AC_SUBST(have_sigwait)
-AC_CHECK_FUNCS(poll kqueue)
+AC_CHECK_FUNCS(poll)
+AC_CHECK_FUNCS(kqueue, [ apr_cv_kqueue=yes ], [ apr_cv_kqueue=no ])
# Check for the Linux epoll interface; epoll* may be available in libc
# but return ENOSYS on a pre-2.6 kernel, so do a run-time check.
@@ -651,6 +652,12 @@
AC_DEFINE([HAVE_EPOLL], 1, [Define if the epoll interface is supported])
fi
+if test "$apr_cv_epoll" = "yes" -o "$apr_cv_kqueue" = "yes"; then
+ addpolling=1
+else
+ addpolling=0
+fi
+
dnl - Checking for missing POSIX thread functions
AC_CHECK_FUNCS([getpwnam_r getpwuid_r getgrnam_r getgrgid_r])
@@ -1341,6 +1348,7 @@
AC_SUBST(stdint)
AC_SUBST(bigendian)
AC_SUBST(aprlfs)
+AC_SUBST(addpolling)
dnl - Checking for string functions
AC_CHECK_FUNCS(strnicmp, have_strnicmp="1", have_strnicmp="0")
Index: include/apr.h.in
===
RCS file: /home/cvspublic/apr/include/apr.h.in,v
retrieving revision 1.137
diff -u -r1.137 apr.h.in
--- include/apr.h.in 5 Jun 2004 11:52:43 - 1.137
+++ include/apr.h.in 23 Sep 2004 02:09:52 -
@@ -220,6 +220,7 @@
#define APR_HAS_LARGE_FILES @aprlfs@
#define APR_HAS_XTHREAD_FILES 0
#define APR_HAS_OS_UUID 0
+#define APR_HAS_ADD_WHILE_POLLING @addpolling@
/* APR sets APR_FILES_AS_SOCKETS to 1 on systems where it is possible
* to poll on files/pipes.
Index: poll/unix/poll.c
===
RCS file: /home/cvspublic/apr/poll/unix/poll.c,v
retrieving revision 1.46
diff -u -r1.46 poll.c
--- poll/unix/poll.c 7 Jul 2004 07:40:12 - 1.46
+++ poll/unix/poll.c 23 Sep 2004 02:09:52 -
@@ -41,7 +41,24 @@
#define HAS_PIPES(dt) (dt == APR_POLL_FILE) ? 1 : 0
#endif
+/* Choose the best method platform specific to use in apr_pollset */
#ifdef HAVE_KQUEUE
+#define USE_KQUEUE
+#elif defined(HAVE_EPOLL)
+#define USE_EPOLL
+#elif defined(HAVE_POLL)
+#define USE_POLL
+#else
+#define USE_SELECT
+#endif
+
+#if defined(USE_KQUEUE) || defined(USE_EPOLL)
+#define USE_RING_SETS
+#include "apr_ring.h"
+#endif
+
+
+#ifdef USE_KQUEUE
static apr_int16_t get_kqueue_revent(apr_int16_t event, apr_int16_t flags)
{
apr_int16
