[lldb-dev] remote server crash -> lldb waits forever in accept()

[Jim Ingham via lldb-dev]

> On Apr 28, 2017, at 4:04 PM, Pavel Labath <labath at google.com> wrote:
> 
> MainLoop was meant to be a general event multiplexer. One of those
> events can certainly be "a certain amount of time expiring".
> So, you could write something like:
> loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() });
> which would translate to an appropriate timeout argument to ppoll.
> 
> 
>>>> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or kevent, so we should probably set that up too.
> Listening for signals is very complicated in multithreaded programs. I
> am not sure about the situation with kevent, but I am sure the ppoll
> based version will not work reliably for this.
> Then there is also the problem of installing a signal handler in a
> shared library (liblldb), which can conflict with whatever is the host
> program doing.
> 
> I would love to have this functionality, as I think it's badly needed
> in a lot of places, but I think it needs to be done the long way round
> and have a sort of an Interrupt function on the SBAPI level (maybe the
> existing SBDebugger.DispatchInputInterrupt would be enough, although I
> am not convinced of the signal-safety of that function), which would
> then trigger an exit from the main loop where necessary. lldb and
> other host programs could then install their own sigint handlers (lldb
> already does btw), and call this function when appropriate.
> 

Yes, this is certainly the right way to do it.  That's how the lldb driver does things.  If we run into troubles with this doing more work than it should in the signal handler, we can make something cleverer.  But the set of things that are in theory signal safe is a small subset of the set of things that are in practice are signal safe.  When I last worked on gdbtk (that was way back in the day), it used to do all the updates of the GUI in a SIGALRM handler.  That should never have worked in theory yet in practice it worked just fine. 

> 
> Let me throw another option out there:
> if lldb-server fails to start because of a borked command line you
> should be able to detect this (waitpid). So then again you are in the
> business of multiplexing two events (accept() and waitpid()) and you
> don't need timeouts. (It will be tricky to multiplex waitpid properly
> without installing a SIGCHLD handler though).
> 

You can do this with kqueues on systems that support them.

Jim


> 
> On 28 April 2017 at 23:17, Chris Bieneman via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>> I think in the common case of listening for a remote connection infinite (or very very long) timeout with signal interrupt is the preferred approach. There are other situations where we use SelectHelper with smaller timeouts, and I think ultimately we should replace SelectHelper with MainLoop because they do basically the same thing.
> 
> +100