Hi, At Tue, 23 Feb 2016 14:10:52 +0000, Victor Orlikowski wrote: > > I have re-read the source for Eventlet's get() on a queue. > I am willing to give the code a try in the lab without the timeouts. > I will report back my results - but I believe that the timeout code in get() > is not significantly different from the code used to schedule an unlock of a > blocked getter on a put().
Did you report the original eventlet bug to the developer community? IMO, eventlet bugs should be fixed in eventlet, but at the same time, ryu can have bug workarounds as a interim solution. > That still leaves me needing a judgment call on the CLI option. > > My reasons for believing that this option can be altered into being a config > file option only: > 1) That option was included at my request, and has only been present in one > release. > 2) Because of that fact, I believe that there will be very few users of that > option currently (perhaps only me - and I do not use it directly). > 3) The option was chosen to have a "good default" that few users were > expected to have to change. This strengthens the case that few users would > have set it directly, and that no/vanishingly few user applications are > expected to be broken by this change. > > I will report back on my testing of the code without timeouts on get(). > Please let me know how to proceed on the command line option; it is my > opinion that user applications are highly unlikely to break as a result of > this change, and that it is better to make the correct change now (so as to > make the behavior correct, and further decrease the likelihood of causing any > issues with user applications). I have no strong opinion on this. Maybe putting a clear notice on the changelog on incompatibility is fine. > Best, > Victor > -- > Victor J. Orlikowski <> vjo@[cs.]duke.edu > > > On Feb 22, 2016, at 10:46 PM, Victor Orlikowski <[email protected]> wrote: > > > > 1) We have a fundamental disagreement about the necessity of the timeouts > > on get(). > > If I understand your position - you contend that they have no merit > > whatsoever. > > I contend (perhaps incorrectly) that they add minimal overhead and ensure > > that the get() operations have a regular "wakeup" to prevent potential > > missed wakeups. My desire for regular wakeups is predicated on my testing > > experiences, which *did* prove a need for the semaphores - but may *not* > > have proved a need for the timeouts. > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
