Problems with the Linux standard library

Several problems have recently been encountered in the ES5 standard library.

One, write write failed but returned successfully

Check the multi-threaded, found that the log inside the number of printing problems, careful examination, found before and after a few words log only print out the front of the 1 or 2 sentences, but from the back of the log, this code is not a problem of fluency.

Write follows the instructions, the atomic operation, does not cache the direct write, returns the write length, and returns 1 failures. So there is no lock on the file in the code that prints the log.

So I wrote a small program, up 10 threads, write a file, write for 5 minutes, the results found that the real successful write less than 1/10, if the failure is that the 1W write is unsuccessful, but the return value of the write failure is neither 1 nor 0, both are successful.

It seems that we can only give Redhat package bug.

Second, in the multi-threaded cut with curl download

When you turn on multithreading using curl, there is a stack error with curl, and under query, ES5 is 3.0 of the library, replaced by 4.0 library, the stack error continues, but the stack error is not the same as before.

I wrote a small program, a number of threads called curl to download, but everything is OK.

So the stack error when the last call to search, found that there are some people and I have the same problem, the following answer is curl in multithreading first domain name resolution error.

The test program in front of me is full of IP, all changed the domain name to download after the error.

The program all the domain name in advance to do the domain name resolution, and then to curl download, all normal.

Third, the timeout setting of curl cancels the alarm signal of the process setting

This is a colleague found, after the download of curl, the timer does not work, a sentence of comments, and finally found that curl is the time-out settings caused by.

Four, the terrible mysql_ping do not quit

Program in the process of running the thread deadlock, look at the call stack, found that one of the threads in the call mysql_ping cannot exit, and this check is locked, causing all threads to deadlock.

As for why mysql_ping not come out, today studied for one night, also did not find the reason. Just a little, but the network stopped, Mysql_ping certainly not back out, at least I waited for one hours, the program did not withdraw from mysql_ping. But in the process of running the program, the network is a pass.

Later study.

Continued: Found in the multi-threaded, frequent mysql_ping cause error or mysql_ping do not quit, changed to Mysql_query failed to mysql_ping, the result mysql_query error caused the program to quit. That's pretty dizzy.

Another: Curl seems to be in multi-threaded still have a certain chance error, set curlopt_nosignal to 1, the situation is much better.

This article is from "Flying Justice Blog" blog, please be sure to keep this source http://xzq2000.blog.51cto.com/2487359/1766847

Problems with the Linux standard library