﻿/*
	© 2014 FrankHB.

	This file is part of the YSLib project, and may only be used,
	modified, and distributed under the terms of the YSLib project
	license, LICENSE.TXT.  By continuing to use, modify, or distribute
	this file you indicate that you have read the license and
	understand and accept it fully.
*/

/*!	\file Workflow.Annual2014.txt
\ingroup Documentation
\brief 工作流汇总报告 - 2014 年度。
\version r312
\author FrankHB <frankhb1989@gmail.com>
\since build 464
\par 创建时间:
	2014-01-01 00:46:52 +0800
\par 修改时间:
	2014-05-23 05:17 +0800
\par 文本编码:
	UTF-8
\par 模块名称:
	Documentation::Workflow::Annual2014
*/

// See "Meta.cpp" for meta descriptions.

$import $WORKFLOW;
$LINE-WIDTH-RESTRICT 0;

$WORKFLOW:
// Following lines are only for logging informal project information.
// See Meta.txt for formal project information.
// See ChangeLog.*.txt for accepted contents.

$2014-01:

report.impl:
The MinGW.org and MinGW-W64 runtime can be distinguished by predefined macros, though version macros are not predefined:
	See http://sourceforge.net/mailarchive/forum.php?thread_name=CAEwic4b-B8%3DQ%3DSV2ptwO36SsCQW%2B6b0N%3DX41t3NHPoDQV%2BKeTw%40mail.gmail.com&forum_name=mingw-w64-public .
	See also http://sourceforge.net/p/predef/wiki/Compilers/ .
There may be some wrong impression of border thickness due to the colors.
	It is easy to see the left vertical line of boundary of the checkbox is thicker in setting panel with violet background.
	When the panel background color is some lighter, here is no such illusion.
	Indeed they have the same thickness. It would be obvious after zoomed (esp. > 2x).
	Actually, no rendering code of checkbox has been changed.
Both the runtime from MinGW.org and MinGW-W64 support multiple versions of Microsoft Visual C++ library(MSVCRT). There are some issues:
	Different verstions of MSVCRT define different symbols with some subtle problems. So they should be same in different toolchain configurations for best compatibility.
		Both of them support at least version 6.0, which is probably the most wide-adopted by Microsoft Windows(they came by default install). The library file name is "msvcrt.lib" for Microsoft Visual C++, accordingly "msvcrt.dll" of the dynamic library and "libmsvcrt.a" as static library for both runtime.
			Though acceptable, but deployment depend on it is not good. The are not publicly guaranteed to be compatible within different versions of Windows.
		For newer versions, the dyanmic libraries name schema is "msvcrXX.dll", in which "XX" is the corresponding concatenated Microsoft Visual C++ main and minor version numbers. For example "msvcrt90.dll" is of VS2008.
			The architecture names (such as "x86" or "amd64") are not related of the file names.
			They are required to be deployed along with the applications, or the end users might able to install correspoinding version of Microsoft Visual C++ Redistributable Package.
		MinGW.org uses 6.0 as default. Things about MinGW-W64 are some complicated, see below.
		Currently MinGW.org's distribution has "libmsvcrt.a", "libmsvcp60.a"(the C++ runtime of VC++ 6.0), and "libmsvcr70.a" to "libmsvcr100.a"(the whole "XX" are 70, 71, 80, 90, 100). It also has corresponding debug versions for latter, i.e. "libmsvcr70d.a" to "libmsvcr100d.a". No newer MSVCRT are supported.
		On the other hand, MinGW.org's distribution also has "libmsvcrt.a", "libmsvcp60.a", and "libmsvcr80.a" to "libmsvcr100.a", but neither other versions("libmsvcr70.a", "libmsvcr71.a") nor debug libraries. However, it has "libmsvcr110.a", which MinGW.org's does not supported.
	There is one extra library, "oldname.lib", to contains the original version of symbol names deprecated by Microsoft (such as POSIX-specific functions, because they are not strictly comforming to ISO C), to map to new names(usually added prefix underscore).
		They are also different in MinGW.org's and MinGW-W64's runtime. There are "libmoldname.a" and "libmoldnameXX.a"("XX" here is also the version numbers, see above) for the former, and only one "libmoldname.a" for the latter.
		See http://sourceforge.net/mailarchive/message.php?msg_id=30556805 .
	Most notable problem is backward compatibility. For example if new "secure" functions(ISO TR 24731-1) like "scanf_s" are used, MSVCRT older than version 8.0 can not be used.
		Actually it is not version 6.0 of MinGW-W64's "libmsvcrt.a". It even exports "__gmtime32" comes from version 8.0.
	Both toolchains use the same built-in specs in compiler driver for use of these libraries, i.e. "-lmsvcrt".
		For better compatiblity, lirary not older than "libsvcrt80.a" should be put explicitly in the linker options to override the default linked "libmsvcrt.a".
		Allocation and deallocation should always be carefully matched within the boundary, i.e. make sure the allocation function and deallocation function for same storage are from the same library.
		Using 2 C runtime library and directly overriding symbols are dangerous.
			Note that libgcc, startfiles or some other library with "atexit" or thread-local storage can be involved with C runtime library's free storage allocation.
		Specs file can be used to specifying completely substition of the C runtime library. It is safer but less convenient.
	Both define the macro "__MSVCRT_VERSION__" in <_mingw.h> to control what version of MSVCRT used.
		If not explicitly specified (i.e. not defined "__MSVCRT_VERSION__" before inclusion of <_mingw.h> or through command line option), both would defined a hard-coded integer value.
		The default values in the libraries are different. It is "0x0600" in MinGW's but "0x0700" in MinGW-W64's.
		A subtle problem is, which not only effected by the version macro. One notable extra macro is "__STRICT_ANSI__", which introduced by several GCC compiler options like "-ansi" or "-pedantic".
		There is a horrible bug in the MinGW.org's <time.h>: if "__MSVCRT_VERSION__ >= 0x800" and "__STRICT_ANSI__" is also defined, then some ISO C functions like "time" are not declared.
			This directly caused <ctime> of libstdc++ (which has 'using ::time;', etc) unusable.
			Maybe more similar bugs, also in different headers.
	The "YFramework.dll" can compiled from b464 after some changes in "YCLib/FileSystem.cpp" but cannot be linked as DLL without changes of some project options.
		The error is of the unresolved symbol "_gmtime32", comes from "pngwrite.o" in "libFreeImage.a".
			It is introduced directly by a call of "gmtime" in function "png_convert_from_time_t" when the configure macro "PNG_CONVERT_tIME_SUPPORTED" is defined.
				The "PNG_CONVERT_tIME_SUPPORTED" configuration is not supported by every platforms, for example Windows CE.
				It is considerable to remove "PNG_CONVERT_tIME_SUPPORTED" in "pnglibconf.h". But it is not a fix for the problems here.
			Currently FreeImage is built with MinGW-W64 toolchain.
			Actually both toolchains can map "gmtime" to "_gmtime32".
			The reason of failure for MinGW.org is that "_gmtime32" is not contained by "libmsvcrt.a" of MinGW.org's, but do contained by MinGW-W64's.
	There are several optional version of MSVCRT containing "_gmtime32", but no one are proper for this scene.
		No MSVCRT 7.0 and 7.1 available for MinGW-W64 toolchain.
		The deployment of MSVCRT 8.0 and 9.0 makes a lot of trouble, if there is no manifest provided.
			For side-by-side assemblies, see http://msdn.microsoft.com/en-us/library/ms235624%28v=vs.80%29.aspx .
			For newer VC++ deployment, see http://stackoverflow.com/questions/6623780/visual-c-2010-changes-to-msvc-runtime-deployment-no-more-sxs-with-manifest .
		For MSVCRT 10.0, symbols "_wstat", "_imp__findfirst" and "_imp__findnext" are not defined.
		No MSVCRT 11.0 or newer available for MinGW.org toolchain.
	Though rebuilt libraries are needed sooner or later, now it is better to have a fix in the project configurations.
		For maintaince reason, the configuration should be the same, without need for users to select one out of two set of configurations.
		Note that a value of "__MSVCRT_VERSION__" not less than 0x0800 causes bugs in MinGW.org's headers when "__STRICT_ANSI__" is defined.
			If this macro is set, only 0x0600 to 0x0700 can be used.
			This macro can be set explicitly to 0x0600 for compatibilities (also for library rebuild).
		For convenience and sanity, no manifest should be introduced.
			There is even no dependency on MSVCRT other than "libmsvcrt.a" in MinGW-W64. It is only to be compatible with the buggy MinGW.org runtime.
			Though introduced a newer dependency, it is somewhat acceptable. YFramework might use some features in that newer version of MSVCRT.
			To introduce manifest only for MinGW.org's compatibility is too expensive.
		Note that mix use of different versions of MSVCRT is dangerous.
		It is relatively safe to use a newer library together with older headers.
		So the final resolution is to implement a custom "_gmtime32" function for MinGW.org toolchain.
Currently object files compiled with '-ffunction-sections -fdata-sections' for GNU ld with '--gc-sections' doesn't work for MinGW PE-COFF targets. It might be fixed in future.
	See https://sourceware.org/bugzilla/show_bug.cgi?id=11539 .
	See http://cygwin.com/ml/binutils/2012-08/msg00216.html .
	See http://sourceforge.net/mailarchive/forum.php?thread_name=CALc40c_v46OnoopJXWbPpQk651JAxWU3UYFmDJy998mPKzD9DA%40mail.gmail.com&forum_name=mingw-w64-public .
Skin is the top level of GUI an application's shell to reflect look and feel. For a reusable GUI toolkit, a visual style is a set of visualized features for UI elements, being a major part of the skin.
YFramework should implement the visual style support. It has been planned from very early reversions.
	Basically, the styles are not for each widgets. They are only effective to style-related widgets.
	The major interface is of namespace "YSLib::UI::Styles", providing abstraction to be stored within the GUI state.
	The previously implemented interface is the palette, which contains a vector of colors to be used in style-related widgets rendering.
	Now the visual style states should be implemented as sets of runtime swichable states.
		The style should be swichable by user code via the GUI state interface. It is the wrapper of the major interface.
		For convenience, the type "string" is used as the key to identify a style.
		It is intended that switching of styles should take effect on classes of widgets. For each paticular instance of widgets, it should be possibly doable to switch in future.
		Switching to a different style should be efficient. That means iteration of each widgets to modify the state is generally inacceptable.
		The basic idea is to bind each styled rendering process as an event handler with parameter type 'PaintEventArgs&&' and to be added to event 'Paint' of the target widget instance.
		The binding of event handler needs a type containing the common implmentation against to code bloat. If per widget style state can also supported here if necessary.
		There should be a way to identify the widget class types. Indexable RTTI type ('std::type_index') is preferred for convenience.
		Choice has been made for the lower layer of the implemention details:
			Static polymorphism is not feasible for some runtime-determinated properties.
			Both interface types(i.e. polymorphic classes having only pure virtual member functions) and manually indexing of handlers are feasible.
			Pros of interface types:
				It is flexible to describe complex details.
				Different sets of explicitly-typed shared state can be stored in the implementation directly.
				Type safety is easily gained through function signatures.
				Inheritance can reduce some common code.
			Cons of interface types:
				Probably more code to write. In the worst case, each interface type should provided to corresponding style-related widget class manually, being hard to reuse.
				Some extraordinary code bloats, linear complexity of total number of style-related widgets.
				Performance decreased for unnecessary virtual calls, though can be optimized away, but not guaranteed and likely not. Note that dispatch of event handler calls are already polymorphic in runtime through 'std::function'.
				It is difficult to use because the concrete interface type should be get statically. This causes it impossible to store all interface types for different widget classes together within the same GUI state without some tricks.
					Type erause or base interface type can be used. Both are expensive in performance and inconvenient to implement.
					Explicitly casts should be used for each binding, obviously inconvenient.
				The ABI is likely complex and not steady. Modifying interface of per class interface is very likely to leads to the user code to be built again.
			Pros of manually indexing of handlers:
				It is simple and direct for event handler binding.
				Code generation and performance is easier to control by the user.
				It is flexible and convenient to use.
				The ABI is likely simpler, and steady when no modification to the indices.
				Indices can have aliases through enumerator or 'const' object declarations.
			Cons of manually indexing of handlers:
				Some lower level details can not be exposed through the interface, which can be inconvenient to use.
				The handler type is limited to event 'Paint'. If needed, the major style interface should be modified.
				Shared states can be supported through the interface should be unique.
					If needed, some additional interface should be added to the GUI state.
					Type erasure or similar techniques can be used to get some intended effects.
				Almost no higher level of optimization at all. The implementation of the language is not aware to the indexing.
			For current requirements, the latter is better.
				It is easy to implement and use.
				It is not very hard to add functionality. Although if needed, the major interface might be modified, but not very probable.
				Indices are not needed to be assigned manually if using enumeration type.
ISO C++11 still uses copy elision for some cases as C++03. There are some special rules.
	See ISO C++11 12.8/31 for conditions.
	If these requirements are met, move constructor of a class can be selected by the overloading resolution without explicitly using 'std::move' or rvalue reference cast. See ISO C++ 12.8/32 for details.
	See also http://isocpp.org/blog/2012/12/quick-q-a-unique-ptr-is-not-copyable-so-why-can-i-return-one-by-value-stack .
Since now ISO C++11 is mandated '<::' to be distinguished as '<' and '::' but not '<:' and ':' if the consequence character is not '>' or ':' , no need to always add space to between '<' and '::'.
	G++ 4.7.1 has not supported.
	G++ 4.8.2 is conforming.

$2014-02:

report.impl:
Trailing path delimiters are allowed in YCLib::FileSystem.
	IEEE POSIX-1003.2 allowed trailing slashes.
		See http://mail-index.netbsd.org/tech-kern/2002/04/28/0016.html .
	Windows API 'FindFirstFile' does not expect trailing delimiters in pattern, so preprocessing of the path string is needed.
		Some implementations may only consider one delimiter. See 'diropen' implemented by MinGW.org.
Both slashes and backslashes can be supported as file system delimiter by Windows API.
	Adding prefix '\\?\' can ignore 'MAX_PATH' limitation and enable large path support.
		Not all API support it.
		Currently, YCLib do not explicitly use it.
	See http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx .
There are some issues against aggresive optimization of moving an object in several contexts.
	For initialization of exception objects, the copy elision would not be performed.
		See N3690 comment CA 23 and CWG 1493.
		See also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3771.pdf .
	Currently moving from returned object is tied closely to the criteria for copy elision.
		See N3690 comment US 13 and CWG 1579.
		Explicit use of 'std::move' can be a workaround.
		This issue was accepted.
	See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3852.html for N3690 comments list.
	There was no consensus for the suggested change for other contexts. See N3690 comment US 12.
	Therefore, explicitly use of 'std::move' and 'std::move_if_noexcept' only should occured when necessary.
'YSTest402r16.nds' cases DeSmuME 0.9.9 x64 crash for unknown reasons.


$2014-03:

report.impl:
Now for YSLib::UI, the default UI event handlers treat the senders to be processed instead of destination widgets where the identity of the sender and the destination widget is true.
	The old rules mean 'this == e.GetSender()' is always true for calling of some events in implementation of YSLib::UI.
		There is no guarantee or guildlines to specify either sender or destination widgets to be used actually in the hanlders in or not in implementation of YSLib::UI.
	The new rules mean senders should always to be considered to be processed at first.
		Actually, the senders are the widgets to be process as possible as it can, i.e. if no dynamic cast needed, 'e.GetSender()' is used instead of '*this' in implementation of YSLib::UI.
	User-provided handlers now can use this assumption to transfer different senders.
	Note that for user-called event, 'this == e.GetSender()' might be false.
	For source different than destination like close button in 'DialogPanel' or widget in 'HoverUpdater', this transformation is obviously not correct for logical reason.
Note that default constructor of instances of 'std::chrono::duration' and similar types are defaulted.
	The underlying values might not always be initialized if there default-initialization is no initialization(see ISO C++ 8.5.3 for details).
	Use interface like 'std::chrono::duration_value::zero()' to get specific zero values.
	Currently there are several use of these types with explicitly default-initialization, which is indeterminated, but not direct used before assignment.
	Consider to use explicit initialization in class definitions to emphasize they are already initialized, if necessary.
Some event-based invalidation of "YSLib::UI::Control" class is removed.
	This is because these invaliadation operations are not always necessary. They are also harmful to performance when not needed.
	Even if the operation is handled, other handlers for painting with same or lower priority might need a more invalidation when more area should be invalidated.
	Invalidation should be performed for controls that painted with different look between focused and non-focused states.
		These controls are all style-related.
		They are "Thumb", "TextList", "ProgressBar", "DialogBox", "DialogPanel", and their derived classes.
			For derived classes, no explicit handlers need to be added. These base classes are directly derived from "Control".
	For "LostFocus" event, following cases are considered:
		For "DropDownList", no further invalidation is needed. The detacher has nothing to do with dropped down list itself.
		For "Menu", no further invalidation is needed. Only the hiding operations perform the invalidation, which is done in "MenuHost::HideRaw".
			But it should be used for focus border painting.
		For "TextBox", a further invalidation is needed and added in the handler for focus border painting.
			Note that the invalidation for caret is not enough.
	For "GotFocus" event, only one case is considered:
		For "Menu", further invalidation for showing is needed. It should be used also for focus border painting.
		For "TextBox", a further invalidation is needed and added as a new handler for focus border painting.

$2014-04:

report.impl:
Call by value or by rvalue refernce for a callable object, a call wrapper or an iterator might be significant different.
	For the notion of call wrappers, see ISO C++11 20.8.1, which was intially introduced in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html .
		A call wrapper "holds" a callable object, not necessarily "owns" a callable object. Be cautious for the lifetime of the underlying callable object.
	Note a call wrapper is MoveConstructible; a call wrapper can be not CopyConstructible; A simple call wrapper is CopyConstructible. See ISO C++11 20.8.2/4.
		Exceptions are strictly restricted to be thrown. No exception are allowed to be thrown in copying a simple call wrapper.
		For moved-only types(which is not CopyConstructible), it should be treated as forwarding call wrapper, i.e. passed as '_fCallable&&'.
		Otherwise, for simplicity, a callable object should be passed by '_tCallable', except when necessarily treated as forwarding call wrapper by design.
			Most uses of callable objects or call wrappers are plainly passed by value.
				Such as the function parameter of the constructor of 'std::function' with exactly 1 parameter.
				The function templates in algorithm library accept callable objects or simple call wrappers passed by value.
			The are two important exceptions:
				The first parameter for the constructor of 'std::bind'.
					The forwarding call wrapper should have been accepted by design.
					See http://wg21.cmeerw.net/lwg/issue817 for details.
				The first parameter for the constructor of 'std::thread'.
					The use cases and reasons are similiar.
					See http://wg21.cmeerw.net/lwg/issue929 for details.
	As of ISO C++ 12.8/32, if the object designated as lvalue is a parameter, it would be firstly moved event if copy ellision criteria in ISO C++ 12.8/31 are not met.
		If used as forwarding of a passed by value callable object, no redundant 'std::move' should be used.
	Similarly, in the standard library, the iteraors in the algorithms are passed by reference primarily.
	For simplicity in YSLib, if and only if noncopyable callable object is intendedly acceptable by design, pass-by-value '_tCallable' should always be used instead of '_fCallable&&'.
		This also means most callable objects should be CopyConstrictible.
		The major general exception is for forwarding function templates, which have templated function parameters like '_tParams&&...'. Some examples:
			General forwarding function templates like 'ystdex::seq_apply', 'ystdex::unseq_apply' and 'ystdex::call_projection::call' in YBase::Functional. They are used for reordering the evaluation as well as forwarding the parameters, so just behave as 'std::bind'.
			General forwarding call wrappers as 'ystdex::expanded_caller', also the helper 'ystdex::make_expanded', in YBase::Functional.
			Forwarding functions templates in YTest::Timing.
			Callers which use 'ystdex::expanded_caller' as underlying implementation in YSLib::Core::YEvent.
	For simplicity in YSLib, an iterator should be passed by value, unless it is an iterator adaptor to generally provide adaption for any other iterator types.
		The general iterator adaptors include, for example, 'ystdex::any_iterator' or 'ystdex::transformed_iterator'.
		All current declarations are conforming. No modification need to be performed.
Unless otherwise specified, the assumption of a resonably reliable C++ implementation should be used for YSLib.
	Differently to Boost, no defensive programing techniques are encouraged to be used to make a poor implementation work.
		Such as double-destruction protection on exception classes.
Rules for exception handling should be uniformed.
	Exceptions handling should generally make use of custom exception classes.
		Pay attention to implicitly declared special member funtions.
		The following rules are forced:
			Make sure no resource could be leak.
			Make sure the destructor is virtual.
			Make sure the move constructor, if any, have nothrow guarantee.
		For YSLib, the exception objects should be MoveConstructible or at least CopyConstructible with trivially copy can be performed. See below for reasons.
	Boost exception handling guildlines are reviewed. See http://www.boost.org/community/error_handling.html . Note it is pre-ISO C++11.
	However, currently most of these rules are not used in YSLib. YSLib follows closely to ISO C++ standard library.
	It's goot to make exception classes derived from std::exception. YSLib follows this guideline. But no assumption should be make generally in user code.
	Virtual inheritance with tagging is not used as Boost library. Because:
		It is somewhat less efficient both in time and space. This is a minor reason, but it nodoubtly exists.
		It might be complex and error-prone.
		The tag dispatching is not always useful.
		States of context might be significant, so no guarantee to not use data members stored in exception.
	There should be no exception thrown during copying an exception object.
		The stricter "not embedding" rule is only necessary when the move constructor is not usable. It is reasonable to not embedded a subobject without nothrow-copy guarantee into an exception object for pre-C++11 code.
		Make the exception object movable, ideally only the initially creation of the excetpion object is concerned with the copy failure.
			This is not guaranteed to be available. See $2014-12 report.impl about non-mandantory of move exception objects.
		But anyway, for std::bad_alloc, even calling of std::terminate is still probably acceptable. Note this handler can be set by std::set_terminate.
		Some standard library classes, notably std::exception, are according to this guideline. Some others are not guaranteed to be according this, like std::runtime_error, which uses object of std::string as a constructor parameter.
		See also http://stackoverflow.com/questions/15831029/not-using-stdstring-in-exceptions .
		Because the YSLib exception objects are MoveConstructible or can be copied trivially, "not embedding" rule is not forced.
	Generally the constructor should throw no exceptions. But this is also not always guaranteed.
		Some standard library classes, notably std::exception, are according to this guideline. Some others are not guaranteed to be according this, like std::runtime_error, whose constructors are without 'noexcept'.
		This guideline is also not forced for YSLib exception objects.
	The what() member function should be overriden only necessary.
		It is usually memroy-sensitive to format the message string.
		YSLib rarely override the what() member function.
	For both implemention and semantics reasons, do not use 'catch(...)' without rethrowing unless really necessary. See also %Documentation::CommonRules @5.10.5.6.

$2014-05:

report.impl:
	Select carefully between const_iterator and iterator for ODR issue. See http://wg21.cmeerw.net/lwg/issue1214 .
There are some similar measurement values for a given image with proper underlying image buffer, both are rectangular in sense of rasterization as pixels.
	Width is the magnitude of the logical image or buffer area in horizontal, or X-axis for 2D coordinates.
	Height is the magnitude of the logical image or buffer area in vertical, or Y-axis for 2D coordinates.
	Stride is generally the distance of two entities measured in a single unit.
		It can be the distance between two pixels in either horizontal or vertical for an image or a buffer.
		For a buffer, the stride is the width of the buffer area.
			Usually it is in pixels.
			For a buffer, it could be sometimes in memory units(esp. bytes) , so being a synonym of the pitch of the buffer, see below.
	Pitch is a particular kind of measurement for a buffer in several different units.
		It is often the synonym of the stride, witch is in pixels.
		It is more often measured in bytes for the underlying scanline of the contiguous memory area.
	E.g for stride vs. pitch: http://msdn.microsoft.com/en-us/library/windows/desktop/aa473780%28v=vs.85%29.aspx .
	See also: http://www.gamedev.net/topic/496278-pitch--stride-/ .
	For images, it is clear the width is the same as the stride betwwen horizontal edge of the pixels.
		In this sense the width is equal to the stride.
		However, usually only width is used to be clear.
	For image buffers, YSLib uses stride to refer the width in pixels, and pitch to refer the width in bytes, or bits if explicitly specified.
		The meaning of stride is harmonized with Android NDK API.
		The meaning of pitch is harmonized with FreeType.
It seems that ::eglSwapBuffers hangs in SharedBufferStack waitForCondition is a bug of Android platform or underlying Linux kernel.
	See: https://code.google.com/p/android/issues/detail?id=20833 .


////

