I should add, this against a very divergent $bigco fork so patch may
not work well.

On Tue, Mar 12, 2024 at 11:07 AM Eric Covener <cove...@gmail.com> wrote:
>
> below + POD wakeup
>
> Did not force the path yet where the listener is started (or fold in
> the scoreboard change )
>
> On Tue, Mar 12, 2024 at 10:54 AM Eric Covener <cove...@gmail.com> wrote:
> >
> > On Tue, Mar 12, 2024 at 10:30 AM Eric Covener <cove...@gmail.com> wrote:
> > >
> > > On Tue, Mar 12, 2024 at 10:19 AM Yann Ylavic <ylavic....@gmail.com> wrote:
> > > >
> > > > On Tue, Mar 12, 2024 at 3:03 PM Eric Covener <cove...@gmail.com> wrote:
> > > > >
> > > > > On Tue, Mar 12, 2024 at 8:48 AM Yann Ylavic <ylavic....@gmail.com> 
> > > > > wrote:
> > > > > >
> > > > > > Maybe it could be:
> > > > > >     if (threads_created) {
> > > > >
> > > > > not listener_started?
> > > > >
> > > > > threads_started>0  could just mean we had no scoreboard issues but
> > > > > pthread_create failed on anything but the first thread.
> > > >
> > > > Don't we want the workers to gracefully stop whenever at least one was
> > > > created, or we may deadlock in clean_child_exit()?
> > >
> > > Yes, I see what you mean now.  I will try to force some pthread_create
> > > errors w/ the patch soon.
> >
> > It seems like if there is no listener yet, the
> > signal_threads(ST_GRACEFUL) will fail to interrupt the queue (because
> > it defers to the woken up listener)
> > Maybe we do it inline before apr_thread_exit/
> >
> >
> >
> > --
> > Eric Covener
> > cove...@gmail.com
>
>
>
> --
> Eric Covener
> cove...@gmail.com



-- 
Eric Covener
cove...@gmail.com

Reply via email to