TT KILEW via llvm-dev
2019-Nov-22 18:59 UTC
[llvm-dev] Updated polling logic in LockFileManager
Hi there. I submitted a patch I llvm that fixed polling logic in LockFileManager https://reviews.llvm.org/D70563 This patch should fix https://bugs.llvm.org/show_bug.cgi?id=20794 There were no activity so I decided to write directly to mail list Is there anyone who can take a look? Thanks. P.S. Are there some additional actions needed for patch to be reviewed? Thanks -- Best Regards, Павло Тайкало / Paul Taykalo skype: tt.kilew, tel.: +38 097 86 1024 1 http://twitter.com/tt_kilew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/4e0bc9df/attachment.html>
David Blaikie via llvm-dev
2019-Nov-22 19:45 UTC
[llvm-dev] Updated polling logic in LockFileManager
Not much for it - it can take a while for folks to get around to reviews. Usually if you haven't heard from anyone within a week it's appropriate to ping the review thread (just reply with the word "ping" or similar) and/or see if you can find some other more appropriate/available reviewers you might be able to rope in. Though looks like you've probably got the right folks on that already On Fri, Nov 22, 2019 at 10:59 AM TT KILEW via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi there. I submitted a patch I llvm that fixed polling logic in > LockFileManager > https://reviews.llvm.org/D70563 > > This patch should fix > https://bugs.llvm.org/show_bug.cgi?id=20794 > > There were no activity so I decided to write directly to mail list > > Is there anyone who can take a look? Thanks. > > P.S. Are there some additional actions needed for patch to be reviewed? > Thanks > > -- > Best Regards, > Павло Тайкало / Paul Taykalo > skype: tt.kilew, tel.: +38 097 86 1024 1 > http://twitter.com/tt_kilew > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/d2394517/attachment.html>
Michael Spencer via llvm-dev
2019-Nov-22 20:19 UTC
[llvm-dev] Updated polling logic in LockFileManager
On Fri, Nov 22, 2019 at 10:59 AM TT KILEW via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi there. I submitted a patch I llvm that fixed polling logic in > LockFileManager > https://reviews.llvm.org/D70563 > > This patch should fix > https://bugs.llvm.org/show_bug.cgi?id=20794 > > There were no activity so I decided to write directly to mail list > > Is there anyone who can take a look? Thanks. > > P.S. Are there some additional actions needed for patch to be reviewed? > Thanks >I recently reviewed https://reviews.llvm.org/D69575 which solves the same problem and seems simpler. Is there anything in your patch not covered by D69575? - Michael Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/bc07639c/attachment.html>
TT KILEW via llvm-dev
2019-Nov-22 21:06 UTC
[llvm-dev] Updated polling logic in LockFileManager
Well, Yes. There are a few differences with the https://reviews.llvm.org/D70563 solution. First of all, in D70563, in case if file will be deleted between `open` and subscription to events, then there'll be maximum timeout. it seems that kqueue is not validating file descriptor, so, in case if file descriptor is already invalid, listening for a kqueue won't give any errors. It will just wait for a timeout and won't receive any events. This behavior can be simply simulated in the code sample, provided in https://reviews.llvm.org/D70563 This is why in D70563 <https://reviews.llvm.org/D70563> registration to the queue and listening to are two different calls. So logic in the path is 1) Register for events (now queue will receive events, but we haven't setup listeners to it yet) 2) Check if lock file was deleted 3) Start receiving events This logic allows preventing race condition if the file was deleted in between open/subscription calls. It's very unlikely to have this race condition, but 90 seconds is pretty long time. Second. in D70563 <https://reviews.llvm.org/D70563> there's an additional event we're listening to check if the process, lock owner has exited. So, in case if owner has died, but for some reason hasn't deleted lock file, we'll exit from the waiting queue. D69575 solution will still wait for file to be deleted for a whole 90seoonds timeout. I'm not sure, how often this lock owner dies without unlocking, but this was in the original code, so I implemented this part as well. On Fri, Nov 22, 2019 at 10:20 PM Michael Spencer <bigcheesegs at gmail.com> wrote:> On Fri, Nov 22, 2019 at 10:59 AM TT KILEW via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi there. I submitted a patch I llvm that fixed polling logic in >> LockFileManager >> https://reviews.llvm.org/D70563 >> >> This patch should fix >> https://bugs.llvm.org/show_bug.cgi?id=20794 >> >> There were no activity so I decided to write directly to mail list >> >> Is there anyone who can take a look? Thanks. >> >> P.S. Are there some additional actions needed for patch to be reviewed? >> Thanks >> > > I recently reviewed https://reviews.llvm.org/D69575 which solves the same > problem and seems simpler. Is there anything in your patch not covered by > D69575? > > - Michael Spencer >-- Best Regards, Павло Тайкало / Paul Taykalo skype: tt.kilew, tel.: +38 097 86 1024 1 http://twitter.com/tt_kilew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/004e84ad/attachment.html>