On Fri, May 1, 2009 at 1:30 PM, Adam Langley <a...@chromium.org> wrote:
> On Fri, May 1, 2009 at 1:23 PM, Mike Belshe <mbel...@google.com> wrote:
> > It's been a while since I dealt with unix signals; but in the work I did,
> > the common trick was to disable signals on all threads except one. Then,
> > you only have to deal with handling signals there. Otherwise, you've
> pretty
> > much always got trouble because you never know which threads will service
> a
> > signal.
> > Does this work? My memory is hazy because it has been too long :-)
>
> We could try this, but it's a little tricky. glibc likes to use
> signals internally sometimes. That might have gone away with
> LinuxThreads, but maybe someone is still using that library? You also
> have to be sure that no 3rd party code is modifying your signal mask.
Agree it can be tricky....
But if 3rd party code uses signals, you're actually probably screwed
already. Signals can arrive on any thread that doesn't mask them. So if
3rd party code relies on signals, other threads can get the signals and need
to service them.
>
>
> There's also a place where we use EINTR to interrupt a sleep system
> call deliberately. Also, I hear noises that we might like to split
> net/ out so that others could use it. In that case, we would want the
> code to function in other signal environments.
pthread_cond_timedwait() may be a better answer than sleep() if you need the
abort capability. Anyway, you certainly don't need a signal for this if you
want to avoid signals.
So, it's a good idea, but I think handling EINTR works better for us.
I'll betcha that signals bite us over and over again in the future until we
nix em altogether. :-)
Mike
>
>
>
> Cheers
>
> AGL
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
