A non-blocking sender simply fails macos tests. Any ideas?

A non-blocking sender simply fails macos tests. Any ideas?

Try again. 😅

In fact, I don't want to support running on MacOS, It's painful to be compatible with MacOS, I want to just keep the compilation passed.@heyanlong @wu-sheng

We know there's indeed a bug. What have you done with the checks? @jmjoy

We know there's indeed a bug. What have you done with the checks? @jmjoy

Maybe the number of endpoints has increased, so the bug of MacOS has emerged.

In fact, I don't want to support running on MacOS, It's painful to be compatible with MacOS, I want to just keep the compilation passed.

That is never a hard requirement. APM focuses on service monitoring in the product env, which is impossible to be a Mac.
So, generally, this is only a question we want to provide this for MAC locally testing, whether it is meaningful for PHP developers. You are more professional than me :)

It should be able to pass all the tests for now, with a more predictable blocking sender but in another standalone thread per fpm. The non-atomic write_all should be solved in another PR.
Though macOS is not our primary target, it does help reveal the bugs. It just should work.

It should be able to pass all the tests for now, with a more predictable blocking sender but in another standalone thread per fpm. The non-atomic write_all should be solved in another PR. Though macOS is not our primary target, it does help reveal the bugs. It just should work.

Great job! Nonblocking sender will be done later.

However, can you also solve the problem of CI by just setting nonlocking to false?

Will there be more and more threads?

There will be one extra thread for each fpm. Simply sending to a non-blocking stream (or so) without retries is much too unreliable. If we could prove that it (send and forget) is acceptable on Linux, maybe it's better to apply these on macOS only (with conditional compilation). Nothing comes at no cost.

However, can you also solve the problem of CI by just setting nonlocking to false?

By rolling back to 9088251?

However, can you also solve the problem of CI by just setting nonlocking to false?

By rolling back to 9088251?

Yes.

We know there are bugs on Reporter (channel/worker). Have we made our decisions over that?

We know there are bugs on Reporter (channel/worker). Have we made our decisions over that?

Well, you can create an issue follow (https://github.com/apache/skywalking-php#how-to-create-issue).

@phanalpha Issue has created. apache/skywalking#9831