Finally!

On thursday, 2009-11-26, I have finally defended my PhD! I'll be starting on the new job on tuesday...

Unpredictability of execution times

I have written an article on intrinsic randomness of modern CPUs that you can fetch here. Originally, I tried to publish it in LWN, but since I haven't heard from their editors in over a week, I'm publishing it this way.

A tricky bug

Today I debugged a piece of code that looked like this:

printf("foobar\n");
if(fork() == 0)
  exit(0);

When the program is run from the terminal, the output is as expected: a single line containing "foobar". However, when the output is sent to a pipe or redirected to a file, two lines appear in the output. (Actually, the problem was a bit more complicated: there were n fork() calls and there were exactly n additional copies of the output). After a bit of digging around and not finding any obvious fault, I asked about it on IRC.

It turned out that stdout is fully buffered when it is attached to a pipe or a file. What happened is that fork() duplicated also the internal I/O buffers, which got flushed after the child process exited, thus producing extra output. I solved the problem by inserting a fflush(NULL); statement before forking, which flushes buffers of all output streams.

Foxit PDF reader -- no go

Today I tested the Foxit PDF reader, version 3.1, since many people recommend it as a faster and lighter-weight alternative to Acrobat Reader. Well, its performance is disappointing: opening a 3MB PDF with Foxit takes 2-3 seconds before the first page is displayed. Opening the same PDF with Acrobat Reader (version 9.1) displays the document with no delay at all. I attempted to open few other PDFs with Foxit, with the same result: annoying pause before I could view the document, but with Acrobat Reader showing the document immediately.

So long Foxit, Acrobat Reader is still my favorite PDF reader.

Unexpected behavior of std::bitset in visual studio 2008

I was writing code for generating prime numbers up to 10^9 (one billion) by sieve of Erathosthenes. So I created a class containing a member of type std::bitset<1000000000> and created an instance of the sieve class within the main function (i.e., allocated on the stack).

When I ran the program, it crashed with stack overflow. Since VC in debug mode implements stack overflow checking, the stack trace was not very helpful -- the program crashes within the _chkstk function. But in my simple test program, the only possible cause of stack overflow could be the instance of the sieve class which contains the bitset member. After lowering the sive's limit to 1000, the program worked fine. It was kinda surprising to learn that std::bitset, unlike std::vector, internally uses an array instead of dynamically allocated storage. (I confirmed this conjecture also by reading the source code of in the corresponding header file.)

OODraw align nonsense...

I've been drawing some diagrams and I attempted to align (center vertically) several objects using one object as the reference object that should not be moved. But OODraw does not offer such feature; what it does instead is to align the selected objects using their bounding box as the reference, which is completely useless. A workaround is to "protect" the size and position of the reference object and then invoke the align command... which are few unnecessary extra clicks here and there. Stupid, stupid, stupid program!

Git's way to the thrashcan

I tried to use git-svn and git for a while, only to get fed up with it today and going back to just using subversion. The thing that pissed me off is that I did git rm on wrong files. With subversion, if you do svn revert before commit, the old copy of the file gets restored (and, of course, removal will not be scheduled for commit).

With git, git checkout should, in theory, do the same. Googling about the problem, I found a tip that I should use git reset. However, neither did that restore the accidentally deleted files. Finaly, I experimented a bit and found out that git reset --hard does the trick. Before experimenting, I did, of course, make a backup of the whole repository to another place.

Now, I'm going back to subversion, which is much more intuitive to use. My work is too valuable to be stored in version control system with which I must experiment to achieve even the simplest of operatons. Yes, I found the --hard option in the documentation, but its explanation was so opaque that I wasn't sure whether it would achieve what I wanted.

Next time I'll be wanting to use a DVCS, I'll use Mercurial, as before.

The meaningless school...

Now, midst in the financial crisis, I've gotten interested in how the economy works in general. Like, the stock market, how can perpetual economic growth be sustainable (in the long run it's exponential), etc. I would also like to know about things that are relevant for real life, like loan calculations, nominal and effective interest rates, forms of long-term savings, etc. And I know zilch about these things.

These things should be a part of basic high-school education. But no, we've been (and today's pupils are still being) overloaded with a bunch of meaningless historical and geographical facts that can be looked up in any online or offline encyclopedia. Among other meaningless stuff that is mostly irrelevant for the practical side of living in the modern world.

Currently I'm busy with writing my PhD, but first priorities on my reading list (after having finished the PhD) are introductory books in macroeconomy, capitalism, and game theory.

Win32 threading API anomaly

I like to split my code into a series of simple helper functions. When developing for multithreaded environment, some of these functions have to be called while a certain mutex is held by the current thread. In POSIX, it's easy to test for a weaker condition, namely that the mutex is locked:

assert(pthread_mutex_trylock(&mtx) == EBUSY)

There is no way to check that the current thread holds the mutex. However, if another thread has locked the mutex, one may hope that pthread_mutex_unlock will return EPERM error code (I don't think that the pthread library is obliged to check for every possible error condition).

Take Win32, and the TryEnterCriticalSection function which returns, according to the documentation: "If the critical section is successfully entered or the current thread already owns the critical section, the return value is nonzero. If another thread already owns the critical section, the return value is zero."

Since I actually expect that the current thread already owns the mutex, the "or" clause in the first sentence makes it impossible to implement even the (weaker) sanity check which is possible under POSIX. Kinda shame.