PHP와 Swoole의 창립자들은 반대표를 던졌고, 코루틴 제안 Fiber는 열띤 논쟁을 촉발시켰습니다.

PHP 커뮤니티는 지난 주(3월 8일) PHP에 Fiber RFC를 추가하기 위한 투표를 시작했습니다.

Fiber RFC의 설명에 따르면 Fiber는 주로 비동기 I/O용 코루틴을 구현하는 데 사용되며 함수 호출을 위한 독립적인 스택 할당, 일시 중지 및 재개 기능을 제공하며 확장으로 PHP에 통합됩니다. https :/ /github.com/amphp/ext-fibre.

계획에 따르면 투표는 3월 22일에 마감됩니다. 최신 데이터는 찬성 38표, 반대 11표입니다. 현재 결과로 볼 때 Fiber RFC는 투표를 통해 PHP에 추가될 가능성이 높습니다(찬성 투표의 2/3로 통과).

현재 공개 투표 결과에 따르면 PHP 창립자 Rasmus Lerdorf와 Swoole 창립자 Han Tianfeng @matyhtf 두 창립자가 모두 반대 투표를 한 것으로 나타났습니다.

Swoole은 PHP용 코루틴 및 고성능 네트워크 프로그래밍 지원을 제공하는 PHP 코루틴 프레임워크로, TCP/UDP 서비스와 고성능 웹을 빠르고 쉽게 구현할 수 있는 다중 통신 프로토콜용 네트워크 서버 및 클라이언트 모듈도 제공합니다. , WebSocket 서비스, 사물 인터넷, 실시간 통신, 게임, 마이크로서비스 등을 통해 PHP는 더 이상 전통적인 웹 분야에 국한되지 않습니다. (Swoole 공식 홈페이지 소개에서) Reddit의

A post는 PHP 내에서 @matyhtf가 보낸 email을 인용하여 Fiber가 AmPHP와 같은 프레임워크에서만 사용될 수 있다는 점과 기타 다른 프레임워크에서만 사용할 수 있다는 점을 언급했습니다. 일반 PHP 웹 프로젝트에는 가치가 없습니다. 이 게시물은 Reddit에서 많은 논의를 불러일으켰습니다. 일부 사람들은 Fiber가 생성기의 업그레이드 버전이며 이를 PHP에 통합하는 것이 개발 및 탐색에 도움이 되지 않을 것이라고 생각합니다. 미래의 비동기 생태학. 일부 사람들은 @matyhtf가 이 제안이 Swoole(Swoole Plus)의 상용화에 미칠 영향을 걱정했기 때문에 반대 투표를 했다는 것에 대해 의문을 제기했습니다.

누군가 이 게시물을 국내 커뮤니티로 옮겼고, 이로 인해 격렬한 토론이 발생하기도 했습니다. @matyhtf는 Fiber가 아직 완성되지 않았으며 PHP에 직접 통합되기보다는 먼저 PECL 확장으로 검증되어야 한다는 그의 견해로 이에 응답했습니다. Zhihu 에 대한 @matyhtf의 답변 :

제가 표현하고 싶은 것은 "Fiber는 주로 amphp 및 Reactphp와 같이 PHP로 구현된 비동기 프레임워크에서 사용되며 일반 PHP 웹 프로젝트에는 큰 가치가 없습니다."라는 것입니다. .

…

Fiber RFC에 대한 내 의견은 PHP 커널 개발자가 결정을 내리기 전에 PHP의 향후 코루틴의 전반적인 기술 시스템과 구현에 대해 명확하게 생각할 수 있도록 먼저 PECL 확장을 권장한다는 것입니다. 실제로 비동기 프로그래밍은 PHP의 오랜 디자인 철학과 프로그래밍 모델을 전복시킵니다. PHP 언어가 공식적으로 Node.js, Golang 및 Swoole과 같은 비동기/코루틴 동시 프로그래밍 모델을 지원하기로 결정했다면 전체 아키텍처와 완전한 구현에 대해 체계적으로 생각해야 합니다.

@matyhtf는 Swoole이 상업용 제품이 아닌 순수 오픈 소스 기술 프로젝트이기 때문에 Fiber RFC에 대한 그의 투표는 Swoole과 아무 관련이 없다고 밝혔습니다. 가능하다면 그는 Swoole의 저작권을 수정하고 swoole-src의 소스 코드를 php-src에 기여할 의향이 있습니다. 그러나 PHP의 코루틴 지원 제안에 대해서는 성급한 결정을 내리기보다는 구문, 표준 라이브러리, ZendVM 측면에서 심도 있게 논의하고 재설계해야 할 중대한 변화라고 생각합니다.

@matyhtf는 기술적인 세부 사항에서 Fiber RFC에 반대하는 이유를 자세히 설명하는 기사(Fiber RFC for PHP 8.1 정보)를 계속 게시했습니다. 그는 사용자에게 정말로 필요한 것은 완전하고 체계적이며 체계적이며 사용하기 쉽고 신뢰할 수 있는 기술 솔루션 세트라고 믿으며 자신의 경험을 바탕으로 고려해야 할 7가지 측면을 제안합니다.

• EventLoop API

• 코루틴(ext-fibre에 해당)

• IO 스케줄러(Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)

• CPU 스케줄러

• 기존 동기식 차단 IO 확장(redis, 컬, php_stream, 소켓, mysqli, pdo_mysql 등)과 내장 함수(sleep, shell_exec, sleep, gethostbyname 등)가 어떻게 코루틴을 지원하고 비동기식 비-IO 확장이 될 수 있습니까? 차단 모드

• 코루틴 통신(채널)

• 서버: PHP-FPM 코루틴 버전을 구현하거나 새로운 코루틴 HttpServer를 제공

@matyhtf가 이에 반대할 타당한 이유를 제시했지만, 앞으로는 많은 사람들이 그의 접근 방식을 승인하지 않는 것 같습니다. 그들은 PHP의 코루틴화를 구현하는 것이 매우 어렵다고 하더라도 이를 병합하기 전에 성숙한 솔루션이 나올 때까지 기다릴 필요가 없으며 단지 Fiber가 완벽하지 않다고 해서 요구 사항을 충족할 수 없다고 추측할 수도 없습니다. 대부분의 사람들. 반대로 Fiber는 최소한의 구현이기 때문에 이를 PHP에 통합하면 사용자에게 큰 유지 관리 부담이 부과되지 않지만 이를 기반으로 더 많은 구현을 수행할 수 있어 다양한 가능성이 열립니다. 사용자가 탐색할 수 있는 코루틴 솔루션의 가능성.

따라서 이 개발자 그룹은 Fiber RFC를 PHP에 추가하는 데 반대할 이유가 없다고 생각합니다. 두 당사자는 서로 다른 관점에서 생각하기 때문에 완전히 반대되는 투표 결과를 내며 둘 다 각자의 입장을 가지고 있습니다. 원래 의도는 PHP를 더 좋게 만드는 것이지만 어쨌든 투표 결과가 결국 승리할 것입니다.