This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi John, On May 8 16:43, john hood wrote: > On 3/29/16 8:49 AM, Corinna Vinschen wrote: > > John, ping? > > Sorry it took so long to reply, but I finally got around to cleaning up > the patchset, I've mailed it separately. I don't see the patchset anywhere. Did I miss your mail or did it fail to make it to this list?!? > I was pretty frustrated at my > slow Windows machine and the friction in dealing with the project, What friction? Was there anything I or others did to alienate you? If there's some problem, please also feel free to discuss on the #cygwin-developers IRC channel @Freenode. You're apparently lurking anyway. > also sick for a while. My sympathy. And no worries if anything takes longer than anticipated. We're not on some tight schedule here :) > > On Mar 20 16:00, Corinna Vinschen wrote: > >> Does it really make sense to build up and break down a timer per each > >> call to select_stuff::wait? This function is called in a loop. What > >> about creating the timer in the caller and only arm and disarm it in the > >> wait call? > > Not fixed. Managing the resource gets more complicated if you hoist it > up to the caller with its various exit conditions. Plus, doing that > doesn't make the minimum or typical cost of select any less, it only > makes the handling of events that select ignores slightly more > efficient. As I see it, ignored mouse events on the console are the > only case where we're likely to see many ignored events, correct me if > I'm wrong. I don't know ATM. I'll have another look when I review the patch but actually we can also just keep it in mind for some later optimization, *iff* it makes sense. > >> Why? It's a lot of additional debug output. Was that only required for > >> developing or does it serve a real purpose for debugging user bug reports > >> in future? If so, I wouldn't mind to have a bit of additional description > >> in the git log to explain the debug statements... > > Split out into a separate patch, apply or discard as you please. I > think it's useful for user bugs (when select is breaking, it really > helps to see what's going on inside) but I don't feel strongly about it. Ok. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |