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.
-Chris
> On Apr 28, 2017, at 2:53 PM, Jim Ingham <jing...@apple.com> wrote:
>
> (1) is okay, except pretty much every time so far I've ever said "operation X
> can't possibly take more than N seconds" somebody finds a case in which that
> assumption was wrong. So you end up having to make the timeouts so long they
> look like stalls anyway... An explicit cancellation gesture is better if
> supportable.
>
> Jim
>
>> On Apr 28, 2017, at 2:20 PM, Chris Bieneman <be...@apple.com> wrote:
>>
>> Ultimately I think the solution here is two changes
>>
>> (1) We should add a timeout to MainLoop so that it doesn't wait forever
>> unless we really want to wait forever.
>> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
>> kevent, so we should probably set that up too.
>>
>> -Chris
>>
>>
>>> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev
>>> <lldb-dev@lists.llvm.org> wrote:
>>>
>>> Seems to me a better UI would be to make ^C interrupt this wait. That
>>> seems to me better than putting in some arbitrary timeout.
>>>
>>> Jim
>>>
>>>> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>
>>>> Hi Chris, Pavel,
>>>>
>>>> I've got a problem launching the hexagon simulator from lldb. It's launched
>>>> the same way that debugserver/lldb-server is launched, with reverse connect
>>>> on a TCP socket. The user can modify the simulator command line (using
>>>> target.run-args), and can easily give a set of options that the simulator
>>>> can't handle. In this case the simulator quits before connecting to lldb,
>>>> and lldb will wait forever for the connection, since TCPSocket::Accept has
>>>> no timeout.
>>>>
>>>> Currently I have a select call before the accept, to make sure there is
>>>> activity on the socket. This doesn't feel right with the new changes using
>>>> MainLoop, so I wanted to see what the list thinks. I believe it will happen
>>>> any time that debugserver/lldb-server quits or crashes before connecting.
>>>> That should be easy to test.
>>>>
>>>> This is what I use, right before the call to accept_loop.Run in
>>>> TCPSocket::Accept:
>>>>
>>>> NativeSocket accept_socket = -1;
>>>> fd_set readset;
>>>> FD_ZERO(&readset);
>>>> for (auto socket : m_listen_sockets) {
>>>> auto fd = socket.first;
>>>> FD_SET(fd, &readset);
>>>> if (fd > accept_socket)
>>>> accept_socket = fd;
>>>> }
>>>> struct timeval timeout = {10, 0};
>>>> int result = ::select(accept_socket + 1, &readset, NULL, NULL,
>>>> &timeout);
>>>> if (result == 0) {
>>>> printf("error: timeout waiting for remote server to connect!\n");
>>>> error.SetErrorString("timeout waiting for remote server to connect");
>>>> return error;
>>>> } else if (result < 0) {
>>>> printf("error: remote server does not exist!\n");
>>>> SetLastError(error);
>>>> return error;
>>>> }
>>>>
>>>>
>>>> Any thoughts this issue?
>>>>
>>>> Ted
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>>> Linux Foundation Collaborative Project
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
