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

From: Scott Zhang (macromarship_at_[hidden])
Date: 2023-12-25 08:32:52

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 <rubenperez038_at_[hidden]> 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-interaction-with-signals
> 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 <rubenperez038_at_[hidden]> wrote:
>> >>
>> >>
>> >> >
>> >> > The code looks like below:
>> >> > void myTask(const char *text)
>> >> > {
>> >> >     sleep(5);
>> >> >     /*for(;;)
>> >> >     {
>> >> >         //sleep(1);
>> >> >     }*/
>> >> >         cout<<"text is "<<text<<endl;
>> >> >   //  cout<<"out"<<endl;
>> >> > }
>> >
>> >
>> > 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.