[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-15 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL354122: [lldb] [MainLoop] Add kevent() EINTR handling (authored by mgorny, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-15 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment. FTR, I've just verified this against NetBSD kernel sources and -- as I suspected and as I believe any reasonable implementation would do -- the only place where EINTR could be returned is when `kevent()` is sleeping, waiting for new events to appear in the event queue. T

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-15 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment. @mgorny let's go through tech-kern@ and later checking FreeBSD/Darwin/OpenBSD. I think it's worth to clarify this in the documentation. As an intermediate version we can land this patch. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58230/new/ https://revi

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. The change looks fine to me. I don't understand all the intricacies of the RetryAfterSignal discussion (AFAICT, it does not matter what you do there, since `RunImpl::Poll` is called in a loop

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment. In D58230#1398529 , @mgorny wrote: > In D58230#1398020 , @krytarowski > wrote: > > > For EINTR we shall use `llvm::sys::RetryAfterSignal` > > > `kevent()` man page indicates: > > > All

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 186915. mgorny edited the summary of this revision. mgorny added a comment. Herald added a subscriber: jfb. Added the test case. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58230/new/ https://reviews.llvm.org/D58230 Files: lldb/source/Host/commo

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment. In D58230#1398020 , @krytarowski wrote: > For EINTR we shall use `llvm::sys::RetryAfterSignal` `kevent()` man page indicates: > All changes contained in the changelist are applied before any pending events > are read from the qu

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment. For EINTR we shall use `llvm::sys::RetryAfterSignal` Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58230/new/ https://reviews.llvm.org/D58230 ___ lldb-commits mailing list lldb-commits@

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. We already had a patch for this, but it kind of got forgotten while we were figuring out how to test it. I had made a test for the behavior here https://reviews.llvm.org/D42206#980045. Could you please try it out and incorporate it into the patch (or write some other kin

[Lldb-commits] [PATCH] D58230: [lldb] [MainLoop] Add kevent() EINTR handling

2019-02-14 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision. mgorny added reviewers: krytarowski, labath. mgorny added a project: LLDB. Herald added a subscriber: abidh. Add missing EINTR handling for kevent() calls. If the call is interrupted, return from Poll() as if zero events were returned and let the polling resume on ne