Comment Proactor (Score 1) 179
can the latest version of Linux now fully support the asynchronous I/O represented by some IOCP-like mechanism that the Proactor pattern can be suitable for it?
Comment Re:halo (Score 1) 3
many thanks.
long sentences can sometimes puzzle me so much.
Comment halo (Score 1) 3
"so he could get health care in prison"
I am sorry but English is not my mother language, therefore I am not quite catch this sentence's meaning, does it mean that the old guy have already in prison for some time, and then he break it to rob $1 in order to get health care, after all that, he will be back to the prison on his own??
Journal Journal: New Home !
I am a Chinese C++ programmer, my job is to develop network servers on POSIX and Win32 platforms.
I desire to communicate with other country's programmers.
My Chinese blog is http://blog.csdn.net/qwidget
Submission + - Weird Events
selfredemption writes: "Q1: (surrendered) istream::gcount() can not work?
A1: Now I apply strlen() function to the read-buffer instead of invocation to gcount() as a temporary alternative.
I should overview and debug the STL and Poco source code to find out what caused this event happened,
but time is not too much for me now, I promise here that I'll be back later when I have time. o(^_^)o
Q2: (cleared) Due to low-level implementation, Poco::FastMutex is recursive on win32 platform, and non-recursive on posix platform.
A2: CRITICAL_SECTION is default to be recursive, therefore FastMutex who just wrapping the EnterCriticalSection() call and do nothing else is not that adequate when whose code comment told me that FastMutex run as a non-recursive lock.
Q3: (cleared) Deadlock incurred in the scope with a scope-lock wrapper whose destructor when leave the scope will release the private mutex that acquired in the constructor at initial point of the scope.
A3: I admit my fault. -_-! I make potential lock-acquire call in the scope even who really does have a scope-lock wrapper."
A1: Now I apply strlen() function to the read-buffer instead of invocation to gcount() as a temporary alternative.
I should overview and debug the STL and Poco source code to find out what caused this event happened,
but time is not too much for me now, I promise here that I'll be back later when I have time. o(^_^)o
Q2: (cleared) Due to low-level implementation, Poco::FastMutex is recursive on win32 platform, and non-recursive on posix platform.
A2: CRITICAL_SECTION is default to be recursive, therefore FastMutex who just wrapping the EnterCriticalSection() call and do nothing else is not that adequate when whose code comment told me that FastMutex run as a non-recursive lock.
Q3: (cleared) Deadlock incurred in the scope with a scope-lock wrapper whose destructor when leave the scope will release the private mutex that acquired in the constructor at initial point of the scope.
A3: I admit my fault. -_-! I make potential lock-acquire call in the scope even who really does have a scope-lock wrapper."
