sig_atomic_t

I found following document for GNU libc. This particular chapter describes how to write the signal procedure. However it may seem to be straight forward, there are many rules which have to be followed.

For instance to exchange the data between the signal handler and user code, up to now I used the int type. This method is not portable and may be unsafe. The reason is because the int type may have from 16 to 64 bits, depending on architecture and types model (for more info please read this document).
The obvious fact is that your int variable access may be atomic on one platform, while non atomic on other.
To solve this issue, you need to use the sig_atomic_t (here is short info) This type does not have strictly defined number of bits but it guarantee that read/write access will be done in atomic manner. Therefore it can be used to exchange the data between the signal handler and user code.

This type does not have associated increment/decrement functions (opposite to similar atomic_t in kernel). Because of this you cannot base on fact that increment operation of the sig_atomic_t variable will be atomic.
The sig_atomic_t type doesn't provide atomic updates. The ++ operator may read the object, and then store a new value on some architectures. That two-access transaction isn't atomic. A signal handler may be invoked between the read and write, and that signal handler may read the old value and act on it or it may store a new value which is about to be overwritten.

Three 0-day bugfixes from M$

It seems that recent fixes from M$ are very interesting. (one for IP stack!)

An Analysis of Underground Forums

If you wonder how officials sees the underground world of cyber crimes you may be interested for that document.

Neverwet

Did you wonder why your clothes making dirty ? Or how the Goretex fabric is working ?
Everything is about the surface tension, and this product can enhance it to the limits. This can be used for instance to make your clothes "water repellent".

DARPA = Skynet ?

Did you heard about Darpa Bigdog ? Well, now we have the Ostrich
The world becomes a creepy place :O

Programing font

Looking for perfect programming font ? here is the whole site about that.

Lock-free vs Wait-free

Ostatnimi czasy interesuje się algorytmami lock-free i wait-free. Dla ciekawych podrzucam kilka artykułów oraz krótka notkę wprowadzająca.

To ensure consistency of a shared data object in a concurrent environment,
the most common method is mutual exclusion, i.e. some form of locking. Mutual
exclusion degrades the system’s overall performance as it causes blocking,
i.e. other concurrent operations can not make any progress while the access to
the shared resource is blocked by the lock. Mutual exclusion can also cause
deadlocks, priority inversion and even starvation.
In order to address these problems, researchers have proposed non-blocking
algorithms for shared data objects. Non-blocking algorithms do not involve mutual
exclusion, and therefore do not suffer from the problems that blocking could
generate. Lock-free implementations are non-blocking and guarantee that regardless
of the contention caused by concurrent operations and the interleaving of
their sub-operations, always at least one operation will progress. However, there
is a risk for starvation as the progress of some operations could cause some other
operations to never finish. Wait-free algorithms are lock-free and moreover
they avoid starvation as well, as all operations are then guaranteed to finish
in a limited number of their own steps. Recently, some researchers also include
obstruction-free [3] implementations to the non-blocking set of implementations.
These kinds of implementations are weaker than the lock-free ones and do not
guarantee progress of any concurrent operation.

http://www.cs.brown.edu/~mph/Herlihy93/herlihy93methodology.pdf
http://www2.research.att.com/~bs/lock-free-vector.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4693&rep=rep1&type=pdf
http://www.cse.chalmers.se/~tsigas/papers/NBMalloc-algorithmica.pdf