[exprimental patch] wakeup instead of polling for dns
Hi, attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think? Cheers, Johannes
Hi Johannes, On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;) AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative. Please let me know if there's another advantage I miss. The cost is using an FLTK mechanism (awake) which we don't in the rest of the code. It looks clean. It should be tested on different platforms/OS. BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case. -- Cheers Jorge.-
Hi Jorge, On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;)
AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative.
Please let me know if there's another advantage I miss.
Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters.
The cost is using an FLTK mechanism (awake) which we don't in the rest of the code.
Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think.
It looks clean. It should be tested on different platforms/OS.
BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case.
I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call. Cheers, Johannes
On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;)
AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative.
Please let me know if there's another advantage I miss.
Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters.
The cost is using an FLTK mechanism (awake) which we don't in the rest of the code.
Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think.
It looks clean. It should be tested on different platforms/OS.
BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case.
I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call.
Ok, attached is another approach that avoids the Fl::lock() and instead uses a Fl::add_fd() which is already used in src/IO. Let me know what you think. Cheers, Johannes
Hi Johannes, Please excuse the delayed answer. On Tue, Feb 14, 2012 at 09:44:24PM +0100, Johannes Hofmann wrote:
On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;)
AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative.
Please let me know if there's another advantage I miss.
Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters.
The cost is using an FLTK mechanism (awake) which we don't in the rest of the code.
Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think.
It looks clean. It should be tested on different platforms/OS.
BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case.
I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call.
Ok, attached is another approach that avoids the Fl::lock() and instead uses a Fl::add_fd() which is already used in src/IO. Let me know what you think.
I just re-read the patch, this time from HG, and it looks clean. The pipe trick is very well tested within dpi so it should work as well as it looks. -- Cheers Jorge.-
On Sun, Feb 19, 2012 at 01:53:13PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
Please excuse the delayed answer.
On Tue, Feb 14, 2012 at 09:44:24PM +0100, Johannes Hofmann wrote:
On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;)
AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative.
Please let me know if there's another advantage I miss.
Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters.
The cost is using an FLTK mechanism (awake) which we don't in the rest of the code.
Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think.
It looks clean. It should be tested on different platforms/OS.
BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case.
I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call.
Ok, attached is another approach that avoids the Fl::lock() and instead uses a Fl::add_fd() which is already used in src/IO. Let me know what you think.
I just re-read the patch, this time from HG, and it looks clean. The pipe trick is very well tested within dpi so it should work as well as it looks.
Ok good. I just committed it as it no longer has the drawbacks of the initial patch I sent. Cheers, Johannes
On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote:
Hi,
attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think?
Well dns resolving is delicate, but not sacred ;)
AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative.
Please let me know if there's another advantage I miss.
Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters.
The cost is using an FLTK mechanism (awake) which we don't in the rest of the code.
Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think.
It looks clean. It should be tested on different platforms/OS.
BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case.
I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call.
... and here comes the patch.
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de