Re: [boost] About weird behavior with boost.asio 1.63 on linux 2.6.15

Hi Ruben. Thanks for replying. The problem is not within sleep. I used sleep to identify where the code got illegal instruction then got killed. The problem, as I described, is that without DBOOST_ASIO_DISABLE_THREADS, it happened after the function ran over. Instead of returning peacefully, got "illegal instruction" error. I think the problem is because the old kernel and gcc I used, the device was made in 2009 so the system is quite old. Besides this , if I use '-fPIC' which gcc, the program crashed either. On Thu, Dec 21, 2023 at 10:39 PM Ruben Perez wrote:

...

BOOST_ASIO_DISABLE_THREADS

Explicitly disables Boost.Asio's threading support, independent of whether or not Boost as a whole supports threads.

I find by -DBOOST_ASIO_DISABLE_THREADS the code works fine.

From the Linux man pages: https://man7.org/linux/man-pages/man3/sleep.3.html sleep is listed as MT-unsafe.

From this thread: https://unix.stackexchange.com/questions/528362/sleep-system-call-on-linux-i... This behaviour is used as a workaround for a bug that is still present in the Linux version you're using. Calling a MT-unsafe function from a multi-threaded environment can yield to behaviour like the one you're describing. Can you please replace the sleep call by a nanosleep (https://man7.org/linux/man-pages/man2/nanosleep.2.html), which is MT-safe (or a console print statement), and see if the behaviour reproduces?

...

Still don't know why

On Thu, Dec 21, 2023 at 2:35 AM Ruben Perez wrote:

...

...

...

The code looks like below: void myTask(const char *text) { sleep(5); /*for(;;) { //sleep(1); }*/ cout<<"text is "<

Does the problem happen if you call any function other than sleep? Doing a blocking sleep in an async task is something to avoid in general. It may be causing interferences with asio's internal scheduler.