<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 <<a href="mailto:j@w1.fi">j@w1.fi</a>><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: <<a href="mailto:20090204201129.GG28563@jm.kir.nu">20090204201129.GG28563@jm.kir.nu</a>><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>
> In order to improve interprocess readability between wpa_supplicant and<br>
> clients of the control interface,<br>
> I propose to fflush the outputs of wpa_printf more often (especially<br>
> 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 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'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>