By default, is STDOUT unbuffered? If not what is the type of its default buffering
Thanks
You didn't give a language, but assuming that you're using C's stdio functions (fopen() etc.) or a language that uses these (and most do, for portability reasons):
It depends on the underlying C runtime library.
Most libraries will try to detect whether STDOUT is connected to a terminal, and avoid buffering if so, and perform block buffering (e.g. my Linux system buffers 8Kb at a time) if not.
Short Answer: By default STDOUT is usually unbuffered. If this is a problem for you, there is fflush(stdout); but that is rarely needed
Related
Is it possible to implement IR receiver on android-things?
1st idea:
Use GPIO as input and try to buffer changes and then parse the buffer to decode a message.
findings:
GPIO listener mechanism is too slow to observe IR signal.
Another way is to read GPIO infinite loop. But all IR protocols strongly depend on time and java(dalvik) in this case is to less accurate.
2nd idea
Use UART
findings:
It seems to be possible to adjust baud rate to observe all bits of a message but UART API require to setup quantity of start bits etc. and this is a problem because IR protocols do not fit that schema.
IMHO at the moment, UART is the only path but it would be a huge workaround.
The overarching problem (as you've discovered) is that any non-realtime system will have difficulty parsing this input directly because of the timing constraints. This is a job best suited to a microcontroller where you can access a timer interrupt. Grab an inexpensive tinyAVR or PIC to manage the sensor for you.
You will also want to use a dedicated receiver sensor (you might already be doing this) to simplify parsing the signal. These sensors include a demodulator, which means you don't have to deal with 38kHz pulse signal and the input is converted into a more standard PWM wave.
I believe you can't process the IR signal in Java because the reading pulses would be quicker than the reading resolution-at least in a raspberry pi. To get faster gpio readings I'm confident you can do in c++ with ndk with the raspberry. Though it's not officially supported there's some tricks to enable it. See How to do GPIO on Android Things bypassing Java on how to write to gpio in c. From there it should be trivial to read in a tight loop. Though I would still try to hook the trigger from Java since so far I have no clear easy idea on how to write/install interrupts in c.
I am using two motes. one has unicast sender program on it and one has uni-cast receiver program on it. Instead of connecting receiving mote with PC, I want to use batteries for mote power source and I want to save outputs of both motes on its mote memory. How can I save output(printf command outputs) of each mote in mote memory and retrieve later on after completion of experiments. Is there any method(built-in functions, commands or code snippet) available for this
P.S. I am using zolertia z1 motes
The straightforward way is to use the xmem interface. The function prototypes are declared in file xmem.h:
https://github.com/contiki-os/contiki/blob/master/core/dev/xmem.h
For Z1 there's a platform-specific implementation of xmem in platform's directory.
If you have never worked with flash memory before, note that the "rewrite" operation is typically not supported by the hardware. You need to erase a whole sector of the flash before you can write anything in that sector. Therefore, the typical usage pattern for dumping sensor data or logs is "write only at the end, never modify". When the current sector is full, erase the next one and write there, and so until the whole flash is full.
Contiki also the Coffee filesystem, which a higher level interface if you need one.
I know there exists read-only values in many languages (final in Java const in C++ etc.) but does such a thing as "Write-Only" values exist? I've heard a variation of this in jokes, such as write-only code, but I'm wondering if this is actually a legitimate concept in computer science. To be honest, I can't see how it would be helpful in any situation, but I'm just wondering.
In unix shell scripting there is a concept of write only memory. But it's not part of any shell or scripting language, it's a device: /dev/null.
The write-only device /dev/null is used to discard output you don't want. Generally by allowing the caller to redirect stdout and/or stderr to it.
There are other write-only memory on a computer. One example is your sound card which on some (older) unix machines are mapped to /dev/audio or /dev/dsp. Writing values to it makes your speaker produce sound but reading from it gets you nothing.
At the lower level of the device drivers themselves, these hardware devices are often connected to a specific memory or I/O address (some CPU architectures don't have separate memory and I/O address - just a single address space shared by RAM and all other hardware). So in a real sense these memory locations are really write-only.
There were certainly some FPUs for PCs that used a somewhat weird setup, by existing as memory-mapped devices. To perform some operations, you would simply write the value you wanted to operate on, to a memory address indicating what operation you wanted performed, the value would then (eventually) be available at another address.
I don't know if you would define this, strictly, as "write-only memory", it is rather memory where (part of) the address is used as an opcode.
In a Haskell program compiled with GHC, is it possible to programmatically guard against excessive memory usage? That is, have it notify the program when memory usage reaches a specified limit, preferably indicating the offending thread.
For example, suppose I want to write a server, hosting a scripting language interpreter, that users can connect to. It's Turing-complete, so programs could theoretically use unlimited memory or time. Suppose each client is handled with a separate thread. If a client writes an infinite loop that consumes memory very quickly, I want to ensure that the thread consumes no more than, say, 1 MB of memory, before being alerted with an exception. I do not want other users to be affected when that happens.
This is probably possible using separate processes and ulimit, but:
I would rather keep it in one program, to avoid the complexity of inter-process communication.
I need to support both Linux and Windows, so I would prefer to keep it platform-agnostic if possible.
Edward Z. Yang and David Mazières have developed an extension to GHC that supports dynamic resource limits, and discuss it at http://ezyang.com/rlimits.html They also provide a version of GHC 7.8 that supports this.
Unfortunately, their work was not included in GHC upstream.
May not be exactly what you want. But, as documented here you have a ghc compile option:
-Ksize, update: Oops, sorry, -K is for stack overflows. Still, you can check that link.
In your example, you may need to modify the source of the scripting language interpreter, make some twists to the memory mgmt. module(s), of course IF it has some managed memory allocation features, the interpreter can complain about an execessive use of memory quota by an API callback to your host application.
For a file on disk, is the Win32 function FlushFileBuffers as reliable and certain as closing the file using CloseHandle then re-opening the file using CreateFile?
Are there circumstances where CloseHandle then CreateFile are better because they save the data correctly to disk when FlushFileBuffers does not?
It is better, CloseHandle() doesn't flush the file system cache write buffers. Beware of the cost, it can take a long time to get the data to the disk. The FILE_FLAG_NO_BUFFERING option for CreateFile allows you to avoid flushing. But it is very expensive and difficult to get right due to the limitations on the written data.
According to the documentation, FlushFileBuffers does write everything to the disk. However, it probably doesn't hurt to test it yourself. I've done BRS testing (big red switch ... well PCs used to have big red switches) in the past, and I found that it did cause everything to be written. After the call to FlushFileBuffers, turn the PC off without a clean shutdown. Turn it back on and see if the data is all there. The behavior may change by OS (in theory it shouldn't ... but you never know). It was quite some time ago that I did tests like that (it was on XP or possibly even Windows 2000).
And I suppose it goes without saying, but you probably don't want to do this testing on a workstation that you really care about.
Although this information is not related to Delphi, but the most deployed SQL-database on earth, sqlite (used for example in Firefox) takes care on such things and you can read a lot ot atomic operations here: http://www.sqlite.org/atomiccommit.html
Below is a quote from the article about FlushFileBuffers
9.2 Incomplete Disk Flushes
SQLite uses the fsync() system call on
Unix and the FlushFileBuffers() system
call on w32 in order to sync the file
system buffers onto disk oxide as
shown in step 3.7 and step 3.10.
Unfortunately, we have received
reports that neither of these
interfaces works as advertised on many
systems. We hear that
FlushFileBuffers() can be completely
disabled using registry settings on
some Windows versions. ...