<div class="gmail_quote"><div><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Date: Wed, 4 Feb 2009 22:11:29 +0200<br>
From: Jouni Malinen &lt;<a href="mailto:j@w1.fi">j@w1.fi</a>&gt;<br>
Subject: Re: [PATCH] suggestion : flush outputs in wpa_printf<br>
To: <a href="mailto:hostap@lists.shmoo.com">hostap@lists.shmoo.com</a><br>
Message-ID: &lt;<a href="mailto:20090204201129.GG28563@jm.kir.nu">20090204201129.GG28563@jm.kir.nu</a>&gt;<br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Feb 03, 2009 at 05:23:48PM +0100, Annie Rota wrote:<br>
<br>
&gt; In order to improve interprocess readability between wpa_supplicant and<br>
&gt; clients of the control interface,<br>
&gt; I propose to fflush the outputs of wpa_printf more often (especially<br>
&gt; stdout).<br>
<br>
This is likely to increase latency and make debug mode differ more from<br>
non-debug as far as timing is concerned which could, at least in theory,<br>
make it more difficult to reproduce some timing issues. Could you please<br>
describe the use case where there are multiple sources producing output<br>
to stdout? Is it clear that the other sources are flushing output as<br>
well? What about the debug-to-a-file option? If it is really going into<br>
a file writing into the same file from another process at the same time<br>
may not be that good of an idea..<br>
<br>
If a better ordering of events is desired, it could be done more<br>
reliable by using timestamps on the event messages from all sources and<br>
then merging the separately generated outputs together and sorting the<br>
result based on the timestamps.<br>
<br>
--<br>
Jouni Malinen &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;PGP id EFC895FA<br>
<br>
<br>
<br>
</blockquote></div>Hi Jouni,<br>
Thanks for your answer, <br>
I suspected this could cause possible performance issues (not observed, but not really tested from my side).<br>
<br>
My use case is simpler than what you imagined, I guess. I just needed
to retrieve the information from wpa_supplicant, and noticed that some
outputs were never displayed in the clients (wpa_cli stdout, or
debug-file output) when produced messages do not fill the output
buffer, as Dan Williams explained in his previous mail.<br>
Of course, when you enable debug mode (-d -dd), the flow is more
important and the buffer flushes naturally, but with low traffic output
messages, some outputs are displayed very late, and the client
analysing it can&#39;t take any decision based on wpa_supplicant feedback,
when asynchronous messages are involved (eg: when is the pairing done
?).<br>
Probably I should directly interface to the control interface, but this was an easy and simple patch to solve my problem.<br>