httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] a bundle of multithreading changes
Date Sun, 07 Dec 1997 18:35:51 GMT


On Sun, 7 Dec 1997, Paul Sutton wrote:

> On Mon, 1 Dec 1997, Dean Gaudet wrote:
> > I haven't looked at the patch yet, but the feature list looks really good
> > :)  Thanks for tracking the unix work. 
> 
> In case it wasn't clear, I was proposing this patch for the current code
> base. It fixes a lot of problems with the MT implementation on Win32 at
> the moment. Certainly something needs doing before we can do a full
> release of 1.3 on Win32. 

Oh yeah I'm definately for it in 1.3.

> > >  - In child_sub_main() (the "worker" thread code) used ptrans for
> > >    the temporary pool, instead of pchild - now consistent with
> > >    Unix child_main() [Incidently I'm not sure why ptrans is a global,
> > >    since it (should) only be used within child_main()?]
> > 
> > ptrans is static now after my changes that created pchild.  I think if you
> > make it local to child_main you end up with setjmp/longjmp issues. 
> 
> I guess so, but surely MT (and certainly multi-fiber) code shouldn't
> really be doing longjmp's? I've pretty much convinced myself that we
> should strip out all the signal stuff from the Win32 code, and work with
> events and polling/blocking-on-events to simulate signals. That's what
> I've done to simulate to a graceful restart SIGUSR1 signal anyway.

You can't get rid of setjmp/longjmp.  Unless you destroy the fiber when a
timeout or sigpipe occurs.  Even thread/fiber creation time is non-trivial
and I'd like to avoid that.  We'll just have to solve the setjmp/longjmp
issues differently -- by nesting into another function after the setjmp. 

Dean


Mime
View raw message