How to make dump() unbuffered?

[BSZ Tim]

In short:
Is window.dump() 's output buffered? If so, is there an easy way to
avoid this buffering?

The longer version, in case you want to ask "why would you do this" or
recommend a better way to approach the problem:
I access through Firefox a webpage that communicates with its server
via AJAX: it receives some update messages every few seconds. I want
to
(1) log these messages, and
(2) on receiving some particular messages, take an action outside FF.

Given that my knowledge on javascript and mozilla architecture is
rather minimal, I went the following way about this: using
Greasemonkey I hijacked the 'processMessages' function in the page's
javascript source. The new version simply does a dump() on each
message and then calls the old version, so the updates from the
messages are rendered. The console output is finally piped to a perl
script (where I am on a much firmer ground), which in turn does all
the logging and calling external programs.

This almost works, with the only problem being that my perl script,
rather than recieving the messages one-by-one, once every few seconds,
gets a batch of them every minute or so. It seems that someone is
buffering on the way and I suspect dump(). Or is it the OS (Windows
XP) console? How can this buffering be disabled so the received
messages are passed to the perl script without delay?

Thanks,
BSZ

[Boris Zbarsky]

Post by BSZ Tim
Is window.dump() 's output buffered?

Here's the relevant part of dump():

4091 if (cstr) {
4092 FILE *fp = gDumpFile ? gDumpFile : stdout;
4093 fputs(cstr, fp);
4094 fflush(fp);
4095 nsMemory::Free(cstr);
4096 }

That's about as unbuffered as we can get on our end; what libc and the
OS (and possibly your shell) do at that point is up to them.

-Boris

[Sanyi]

Post by BSZ Tim
Is window.dump() 's output buffered?

4091   if (cstr) {
4092     FILE *fp = gDumpFile ? gDumpFile : stdout;
4093     fputs(cstr, fp);
4094     fflush(fp);
4095     nsMemory::Free(cstr);
4096   }
That's about as unbuffered as we can get on our end; what libc and the
OS (and possibly your shell) do at that point is up to them.

Thanks for the answer and exonerating dump(). With some trial and
error I managed to see unbuffered output, when running FF with the -
console option.

<offtopic>
After some research I also found that problems caused by buffering in
pipes are documented in e.g msys+rxvt consoles; see
http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/3113.html
or http://old.nabble.com/problem-with-unbuffered-read-ts1173321.html#a1173321

Given that I need the pipes for my setup, the recommended workaround
(msys+cmd) does not work. I ended up with the kludge of sending a 4K
padding with each message to make sure that the buffer flushes.
</offtopic>

[BSZ Tim]

Post by BSZ Tim
Is window.dump() 's output buffered?

4091   if (cstr) {
4092     FILE *fp = gDumpFile ? gDumpFile : stdout;
4093     fputs(cstr, fp);
4094     fflush(fp);
4095     nsMemory::Free(cstr);
4096   }
That's about as unbuffered as we can get on our end; what libc and the
OS (and possibly your shell) do at that point is up to them.

Thanks for the answer and exonerating dump(). With some trial and
error I managed to see unbuffered output, when running FF with the -
console option.
<offtopic>
After some research I also found that problems caused by buffering in
pipes are documented in e.g msys+rxvt consoles; see
http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/3113.html
or http://old.nabble.com/problem-with-unbuffered-read-ts1173321.html#a1173321

Given that I need the pipes for my setup, the recommended workaround
(msys+cmd) does not work. I ended up with the kludge of sending a 4K
padding with each message to make sure that the buffer flushes.
</offtopic>

BSZ