Sợi ReactPHP

chưa đọc

Chào Peter,

Xin chào Aaron, điều này rất thú vị với tôi. Tôi có thể hỏi tại sao cách tiếp cận này như
trái ngược với các mô hình khác như lời hứa, coroutines, v.v.?
async/await trong phạm vi tương lai và tôi cho rằng hầu hết các mẫu này có thể
thực hiện một khi có một chức năng cơ bản. Về cơ bản, tại sao
sợi thay vì x?

Lời hứa dẫn đến sự cố "Chức năng của bạn có màu gì" như được mô tả trong phần giới thiệu RFC. Trả lại lời hứa từ các chức năng có nghĩa là các chức năng gọi các chức năng đó cũng phải trả lại lời hứa, dẫn đến toàn bộ ngăn xếp cuộc gọi cần trả lại lời hứa

Sợi là một phương pháp thực hiện các coroutine hoặc các chức năng có thể bị gián đoạn. Các lời hứa có thể vẫn được sử dụng làm trình giữ chỗ trong các thư viện sử dụng sợi, nhưng các coroutine được viết bằng sợi không phải trả lại một trình giữ chỗ khác. Các sợi cho phép mã không đồng bộ không thể phân biệt được với mã đồng bộ hóa, trái ngược với cách tiếp cận trong đó các chức năng không đồng bộ phải trả về một lời hứa

Bạn cũng đã đề cập rằng điều này không thực sự được sử dụng trực tiếp, nhưng với
một thư viện như AMPHP. LÀ kỳ vọng rằng I/O không chặn
chức năng như trình điều khiển cơ sở dữ liệu và hoạt động tập tin được cung cấp bởi
cả thư viện?

Vì hầu hết mã được viết cho PHP đều bị chặn, vâng, các thư viện/khung công tác như vậy sẽ cần cung cấp chức năng như trình điều khiển cơ sở dữ liệu. Cả AMPHP và ReactPHP đều đã có sẵn trình điều khiển không đồng bộ cho một số hệ thống cơ sở dữ liệu phổ biến khác nhau. Trình điều khiển postgres, mysql và redis của AMPHP đã có phiên bản sử dụng sợi quang

Tôi hy vọng tôi không chỉ trích, tôi chỉ tò mò. Cảm ơn bạn vì
thúc đẩy điều này về phía trước, vì async là thứ mà PHP đang thiếu và nên
có IMO để so sánh thuận lợi với các lựa chọn thay thế khác

Bạn đã không tỏ ra quan trọng chút nào. Đây là những câu hỏi hay để hỏi. Tôi cũng nghĩ rằng nếu PHP thêm hỗ trợ cho mã không đồng bộ thì nó sẽ thuận lợi hơn so với các ngôn ngữ khác. Tôi nghĩ rằng các sợi mang lại lợi thế khác biệt khi sử dụng lời hứa cho mã không đồng bộ

Chúc mừng,
Aaron Piotrowski

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

use namespace HH\Asio;

async function async_task(): Awaitable {
  await Asio\usleep(1000000);
}

<<__EntryPoint>>
function main(): void {
  $start = microtime(true);

  $async = async {
    concurrent {
      await async_task();
      await async_task();
    };

    return 'hello';
  };

  $result = Asio\join($async);

  printf('Result: %s ( %f )', $result, microtime(true) - $start); // output "Result: hello ( 1.010382 )"
}

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

chưa đọc

Chào mọi người

Tôi xin giới thiệu một RFC để thêm các sợi full-stack vào PHP. https. //wiki. php. mạng/rfc/sợi

Các sợi chủ yếu được sử dụng để triển khai các luồng xanh hoặc coroutine cho I/O không đồng bộ. Sợi tương tự như sợi, ngoại trừ sợi tồn tại trong một sợi đơn và yêu cầu lập lịch trình hợp tác của sợi theo quy trình. Vì các sợi quang không yêu cầu chuyển đổi ngữ cảnh CPU đầy đủ nên chúng nhẹ và hiệu quả hơn so với đa xử lý hoặc phân luồng để chờ I/O

Việc triển khai dưới dạng tiện ích mở rộng có tại https. //github. com/amphp/ext-sợi

Sợi là một tính năng phức tạp. RFC chứa nhiều ví dụ và liên kết đến mã sử dụng sợi để giúp giải thích và chứng minh những gì có thể, tuy nhiên tôi chắc chắn sẽ có nhiều câu hỏi và mối quan tâm hơn. Rất mong nhận được phản hồi và thảo luận

Điều này thật thú vị và có khả năng rất hữu ích

Tôi tò mò về cách bạn đề xuất quyền truy cập vào bộ nhớ dùng chung trên các sợi quang?

-Mike

P. S. Bạn đã xem chức năng đồng thời như trong GoLang[1] e. g. kênh, trong đó câu thần chú là "Không giao tiếp bằng cách chia sẻ bộ nhớ; thay vào đó, hãy chia sẻ bộ nhớ bằng cách giao tiếp?"

[1]

Chào Mike,

Các sợi không thay đổi bản chất đơn luồng của PHP. Chỉ một sợi quang có thể chạy cùng một lúc, vì vậy bộ nhớ không thể được sửa đổi đồng thời

Có các vấn đề về đồng bộ hóa khi viết mã không đồng bộ bằng cách sử dụng các coroutine có ngăn xếp hoặc có ngăn xếp, vì bất kỳ ai đã từng làm việc với AMPHP hoặc ReactPHP đều có thể cho bạn biết. Nhiều sợi (coroutines, green-threads, bất cứ thứ gì bạn muốn gọi chúng) sẽ xen kẽ thực thi. Nhiều sợi xen kẽ có thể thay đổi trạng thái đối tượng giữa tạm dừng và tiếp tục, điều mà tôi đoán là điều bạn lo ngại hơn là sửa đổi đồng thời theo nghĩa đen có thể xảy ra với các luồng. RFC không cung cấp các công cụ để đồng bộ hóa truy cập bộ nhớ, vì chúng có thể được triển khai trong không gian người dùng. Fibers không cung cấp toàn bộ API, chỉ cần API "bare-metal" để triển khai các kiểu đồng thời khác nhau trong mã không gian người dùng

AMPHP cung cấp các công cụ đồng bộ hóa chẳng hạn như mutexes, semaphores, bưu kiện và kênh trong https. //github. com/ampphp/đồng bộ https. //github. com/amphp/đồng bộ hóa và https. //github. com/ampphp/song song https. //github. com/ampphp/song song. Các thư viện khác có thể cung cấp các công cụ tương tự, mặc dù có lẽ với cách tiếp cận khác. Chúng tôi cũng thích kiểu Go của đồng thời và tìm cách mô phỏng nó trong AMPHP v3

Chúc mừng,
Aaron Piotrowski

chưa đọc

Xin chào Mike Schinkel,

Điều này thật thú vị và có khả năng rất hữu ích
 
Tôi tò mò về cách bạn đề xuất quyền truy cập vào bộ nhớ dùng chung trên các sợi quang?

(Tôi bắt đầu viết bài này trước khi Aaron gửi phản hồi khác)

[Đồng thời không phải là song song](văn bản của https. //Blog. golang. org/waza-talk , không phải video),
và RFC này không thêm song song vào php
Thay vào đó, RFC là một đề xuất để làm cho đồng thời dễ dàng hơn
Email thông báo rfc nói rằng "sợi tồn tại trong một luồng"
Một cáp quang sẽ phải giải phóng quyền kiểm soát một cách rõ ràng cho bộ lập lịch trình sau khi sửa đổi biến $GLOBALS, v.v.

Theo tôi hiểu, đề xuất này tương tự như cách hoạt động đồng thời trong nút cho mã được viết bằng JS - https. // stackoverflow. com/câu hỏi/29977049/how-does-concurrency-work-in-nodejs
(ở chỗ chỉ có một luồng, nhưng khác ở chỗ việc lên lịch được thực hiện thủ công)

Thanks,

• tyson

chưa đọc

Chào Peter,

Tôi đã chơi xung quanh với điều này một chút và tôi có thêm một số câu hỏi. Tôi thấy bạn gần đây đã thay đổi cách thức hoạt động của

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

1, biến nó thành

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

2 và thêm một số chức năng "là" để phù hợp hơn với sợi quang thông thường

Vì bản thân

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

1 cũng là một sợi, tại sao nó cần phải là một lớp riêng biệt?

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

Bạn có thể có hai hoặc nhiều lịch trình không?

Bạn có thể có hai hoặc nhiều bộ lập lịch trong một tập lệnh. Chỉ một người có thể chạy cùng một lúc

Bạn có thể thực hiện mà không cần lập lịch trình và gọi một sợi quang bên trong một sợi quang theo cách đệ quy không?

Thiết kế này yêu cầu phải nhập một sợi lập lịch giữa việc tạm dừng một sợi của người dùng và tiếp tục một sợi của người dùng khác. Sợi người dùng được thiết kế độc lập. Nếu hai sợi người dùng cần giao tiếp, họ nên sử dụng thứ gì đó tương tự như các kênh của Go để trao đổi dữ liệu

Liên quan đến vấn đề đó, tôi nhận thấy không thể gọi

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

4 từ bên trong bộ lập lịch, tại sao vậy?

Một cáp quang của bộ lập lịch không thể bị treo hoặc tiếp tục bởi mã người dùng, vì vậy sẽ không hữu ích khi tham chiếu đến cáp quang đó

Ngoài ra, theo cách khác, thay vì biến bộ lập lịch thành một lớp duy nhất cần được chuyển qua, tại sao không đi theo lộ trình PHP "truyền thống" hơn và tạo mẫu cho nó sau

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

5,

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

6 và các loại hàm đó?

Điều này sẽ loại bỏ nhu cầu về một lớp lập lịch trình đặc biệt và nhu cầu chuyển lịch trình trở lại

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

9. Mỗi cuộc gọi

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

9 sẽ nổi lên thông qua các cuộc gọi lại của bộ lập lịch biểu đã đăng ký. Điều này sẽ cho phép các bộ lập lịch cạnh tranh làm việc tốt hơn với nhau, thay vì một bộ lập lịch phải hoàn thành trước khi bộ lập lịch cao hơn có thể chạy vòng lặp tiếp theo

Bộ lập lịch được nhập là dành riêng cho mã gọi

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

$fiber = Fiber::this();
$callbacks = [
    fn() => $fiber->resume("Test"),
];

register_fiber_scheduler(function() use ($callbacks) {
    foreach ($callbacks as $callback) {
        $callback();
    }
});

$value = Fiber::suspend();

echo "After resuming main fiber: ", $value, "\n"; // Output: After

Dù bằng cách nào, không phải sợi quang đã biết nó đang ở trong bộ lập lịch nào khi nó tạm dừng sao?

Không, một sợi quang có khả năng sử dụng các bộ lập lịch khác nhau tại các điểm treo khác nhau. Bộ lập lịch khởi động một sợi không nhất thiết phải là bộ lập lịch duy nhất tạm ngưng sợi

Hy vọng rằng điều đó sẽ giúp hiểu cách thức hoạt động của API. Vui lòng xem cách amphp v3 sử dụng sợi trong các ví dụ này https. //github. com/amphp/amp/tree/v3/examples/pipeline hoặc trong sợi phản ứng https. //github. com/trowski/react-fiber/tree/master/examples trong đó API Fiber được xử lý bởi thư viện thay vì mã “ứng dụng”

Chúc mừng,
Aaron Piotrowski

chưa đọc

Hi Aaron,

đây là một chức năng rất thú vị và đáng hoan nghênh. tôi phải đi
thông qua RFC một vài lần, nó chưa bao giờ nghĩ đến hoặc làm việc với
các sợi trước đây, sẽ có thêm phản hồi sau khi tôi nắm được
chi tiết hơn

Từ POV của tôi, các hiệu ứng trên các tiện ích mở rộng khác là yếu tố quan trọng nhất,
bạn đã có một phần dành cho Xdebug, Parallel và pcov. Nhưng mà
điều này ảnh hưởng như thế nào đến Trình cấu hình quản lý chồng khung của riêng họ,
tất cả các cuộc gọi chức năng hoặc những cuộc gọi được chọn cụ thể. Tôi. e. xhprof,
thủy triều, datadog, newrelic, v.v.

Chào Benjamin,

Xin lỗi vì một chút chậm trễ trong việc trả lời. Tôi đã bận rộn trong vài ngày qua

Các trình cấu hình quản lý chồng khung của riêng chúng sẽ phải được sửa đổi để tính đến các sợi. Tiện ích mở rộng hiện cung cấp API để truy cập vào sợi hiện tại và xác định duy nhất từng sợi khác nhau

API nội bộ cho điều này sẽ cần thảo luận thêm giữa những người đóng góp nội bộ còn lại và hy vọng là tác giả của các tiện ích mở rộng đó. Tôi đã bỏ qua bất kỳ API nào cho điều này từ RFC vì nó không ảnh hưởng đến mã người dùng

Hiện tại, bất kỳ PHP Profiler nào cũng chỉ phải quản lý một ngăn xếp "open
khung". Với Sợi cho mỗi sợi phải mở ngăn xếp mới

Tiện ích mở rộng có biết sợi "hoạt động" là gì để từ
zend_execute_data Tôi biết tôi cần đẩy một khung hình mới vào ngăn xếp nào đang mở
khung?

Bốn chức năng hiện được cung cấp để xác định sợi thực thi hiện tại

zend_fiber *zend_get_root_fiber()
zend_fiber *zend_get_current_fiber()
zend_long zend_fiber_get_id(zend_fiber *fiber)
zend_long zend_fiber_get_current_id()

Những thứ này cho phép bạn lấy gốc và sợi quang hiện tại cũng như ID được liên kết với sợi quang
ID sợi là duy nhất cho quy trình và không bao giờ được sử dụng lại, vì vậy nó có thể được sử dụng để xác định khung ngăn xếp mở nào sẽ đẩy khung

Bạn có thể thêm một phần vào RFC giải thích cách chuyển đổi giữa các sợi
có hoạt động về mặt zend_execute_data "tiếp theo" và "trước đó" được chạy không?
Điều này cũng sẽ rất thú vị để hiểu cách hoạt động của dấu vết ngăn xếp, vì
ví dụ debug_print_backtrace

Tôi đã thêm một phần ngắn trong Câu hỏi thường gặp có tên "Các ngăn xếp thực thi được hoán đổi như thế nào?",

Các vết lùi hiện bị giới hạn chỉ bao gồm sợi hiện đang thực thi. Có thể bao gồm các dấu vết ngược của sợi trong ngăn xếp thực thi, nhưng tôi gặp sự cố khi cố gắng triển khai điều này trong tiện ích mở rộng trong khi tắt máy do ngăn xếp được giải phóng. Một cái gì đó tôi nghĩ có thể được giải quyết nếu thêm vào lõi với sự trợ giúp của ai đó quen thuộc hơn với cách lưu giữ các tham chiếu đến các ngăn xếp này và những gì nên sửa đổi trong các hàm tạo dấu vết ngược

Chúc mừng,
Aaron Piotrowski

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

chưa đọc

2021年2月2日 上午11. 04，tyson andre tysonandre775@hotmail. com 写道：

Xin chào Aaron Piotrowski,

Tôi xin giới thiệu một RFC để thêm các sợi full-stack vào PHP. https. //wiki. php. mạng/rfc/sợi

Các sợi chủ yếu được sử dụng để triển khai các luồng xanh hoặc coroutine cho I/O không đồng bộ. Sợi tương tự như sợi, ngoại trừ sợi tồn tại trong một sợi đơn và yêu cầu lập lịch trình hợp tác của sợi theo quy trình. Vì các sợi quang không yêu cầu chuyển đổi ngữ cảnh CPU đầy đủ nên chúng nhẹ và hiệu quả hơn so với đa xử lý hoặc phân luồng để chờ I/O

Việc triển khai dưới dạng tiện ích mở rộng có tại https. //github. com/amphp/ext-sợi

Sợi là một tính năng phức tạp. RFC chứa nhiều ví dụ và liên kết đến mã sử dụng sợi để giúp giải thích và chứng minh những gì có thể, tuy nhiên tôi chắc chắn sẽ có nhiều câu hỏi và mối quan tâm hơn. Rất mong nhận được phản hồi và thảo luận

Tôi đã xem repo amphp/ext-fiber cách đây vài tuần - không có gì nổi bật như một mối quan tâm lớn nhưng tôi chỉ quen thuộc với việc phân luồng,
Một nhận xét nhỏ là sẽ dễ đọc các trường hợp kiểm tra phpt hơn nếu

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

8
bao gồm tên cơ sở của tệp trong đầu ra kiểm tra dấu vết lỗi thay vì chỉ

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

9, v.v.
(e. g. thử nghiệm/002-ném. phpt)

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

Tôi không thấy trong các trường hợp thử nghiệm/rfc
Làm thế nào để các macro

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

0/

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

1/

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

2 và macro

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

3 được xử lý sau một lỗi nghiêm trọng?
Tôi không chắc chắn 100% - tôi nghĩ những thứ đó sử dụng setjmp/longjmp trong nội bộ - liệu các lỗi nghiêm trọng có tiếp tục hoạt động nếu có lỗi nghiêm trọng từ bên trong sợi quang
(e. g.

Stack trace:
#0 %s(%d): {closure}()
#1 %s(%d): Loop->tick()
#2 %s(%d): Loop->run()
...

4 trên một tệp có lỗi nghiêm trọng trong thời gian biên dịch, chẳng hạn như các tham số trùng lặp)
Tôi quên chính xác cách họ làm việc, e. g. trong ngữ cảnh của một máy chủ web trước RFC này - trong nháy mắt, tôi đoán một lỗi nghiêm trọng không thể khôi phục sẽ khiến nhân viên tắt máy
Việc ở trong một sợi quang khác và ngăn xếp C khác có cản trở quá trình tắt máy do các lỗi nghiêm trọng không?

Thanks,
-Tyson Andre

--

Để hủy đăng ký, hãy truy cập. https. //www. php. mạng/hủy đăng ký. php

Xin chào Tyson Andre,

Chúng tôi đã thử hai giải pháp khác nhau trong Swoole để giải quyết vấn đề này

Vì mỗi coroutine có một ngăn xếp C độc lập và vị trí ngăn xếp C được lưu bởi gói cứu trợ là bất hợp pháp trong các coroutine khác, nên chúng tôi phải thực hiện dự phòng zend_try và zend_catch trong mỗi coroutine. Khi xảy ra lỗi nghiêm trọng, hãy chuyển đến ngăn xếp C tương ứng với hàm main(), sau đó thoát qua quy trình bình thường của PHP. Tuy nhiên, phương pháp này không an toàn trăm phần trăm. Rất khó để Swoole tái chế các coroutine còn sống sót khác. Trong trường hợp cực đoan, một số vấn đề về bộ nhớ vẫn có thể xảy ra

Tôi thích cái khác hơn - Do những nỗ lực tuyệt vời của PHP8, các lỗi nghiêm trọng trong PHP đã giảm đi rất nhiều và được thay thế bằng các cơ chế ngoại lệ. Do đó, khi xảy ra lỗi nghiêm trọng với khả năng cực kỳ thấp, thoát trực tiếp qua exit() có thể là cách an toàn nhất. Tất nhiên, điều này sẽ khiến register_shutdown_function bị lỗi

Trân trọng,
hai người

chưa đọc

Này Nikita,

Cảm ơn vì lời đề nghị. Công thái học của I/O không đồng bộ trong PHP chắc chắn còn lại

một cái gì đó được mong muốn ngay bây giờ, và những cải tiến trong lĩnh vực này là
hoan nghênh

Bất chấp những lời giải thích của bạn trong RFC và chủ đề này, tôi vẫn gặp khó khăn
khó hiểu mục đích của FiberScheduler

Hiểu biết hiện tại của tôi là FiberScheduler là một loại đặc biệt của
sợi quang mà người dùng không thể lên lịch rõ ràng -- đó là
tự động lên lịch bởi Fiber. đình chỉ () và tự động hủy lịch trình
bằng sợi. sơ yếu lý lịch () hoặc Fiber. ném(). Đó là sợi chạy giữa
sợi. ) Điều đó nghe có chính xác không?

Vâng, đó là chính xác. Sợi được sử dụng cho đa tác vụ hợp tác và
thường có một bộ lập lịch duy nhất chịu trách nhiệm lên lịch. Nhiều
lịch trình sẽ chặn lẫn nhau hoặc chờ đợi bận rộn. Vì vậy, có nhiều
bộ lập lịch không được khuyến khích mạnh mẽ trong các ứng dụng chạy dài, tuy nhiên,
nó có thể được chấp nhận trong các ứng dụng truyền thống, tôi. e. PHP-FPM. Trong
PHP-FPM, nhiều bộ lập lịch chặn nhau một phần vẫn tốt hơn
hơn là chặn hoàn toàn mọi hoạt động I/O

Điều không rõ ràng đối với tôi là tại sao sợi lịch trình cần phải được
phân biệt với các loại sợi khác. Nếu chúng ta muốn gắn bó với cái chung
cách tiếp cận, tại sao là Fiber. đình chỉ($scheduler) không phải Fiber. transferTo($sợi),
trong đó $fiber sẽ là sợi đóng vai trò là bộ lập lịch (nhưng nếu không thì
Sợi thông thường)?
các sợi sẽ biểu cảm nhất và tạo ra giao diện nhỏ nhất

Có một vài lý do để tạo sự khác biệt ở đây

• SchedulerFibers được chạy đến khi hoàn thành ở cuối tập lệnh, đây không phải là trường hợp
  cho sợi thông thường
• Sợi kết thúc cần một sợi để quay trở lại. Đối với người lập lịch trình, thật tốt nếu
  một sợi được nối lại kết thúc, đối với các sợi thông thường, nó sẽ là một ngoại lệ nếu
  sợi quang của bộ lập lịch kết thúc mà không tiếp tục lại một cách rõ ràng
  chất xơ
• Giữ sợi quang trước đó cho mỗi điểm treo là phức tạp nếu
  không phải là không thể để có được đúng và thường làm phức tạp việc thực hiện
  và tải nhận thức, xem ví dụ sau

chính -> A -> B -> C -> A (chấm dứt) -> C (trước đó) -> B (chấm dứt) ->
C (trước, chấm dứt) -> chính

Trong ví dụ trên, danh sách liên kết quang trước đó từ C trở lại chính
cần được tối ưu hóa tại một số điểm, nếu không thì A và B cần được giữ nguyên
bộ nhớ và do đó rò rỉ bộ nhớ cho đến khi C được tiếp tục

Tôi chắc rằng Aaron có thể trình bày một vài lý do khác để tiếp tục chia tay

Giải pháp thay thế hạn chế hơn là sử dụng Fiber. đình chỉ () trở lại
sợi gốc (cái nối lại() nó). Ở đây, sợi gốc
hiệu quả trở thành sợi lập lịch. Nếu tôi hiểu đúng, lý do
tại sao bạn không muốn sử dụng phương pháp đó, là nó không cho phép bạn
gọi một số hàm AMP từ sợi {main}, tạo bộ lập lịch ở đó
và sau đó xử lý {main} giống như bất kỳ sợi nào khác. Đúng không?

Đúng, điều này sẽ không cho phép Fiber cấp cao nhất. đình chỉ(). Nó cũng sẽ làm cho
bên bắt đầu / nối lại trước đó chịu trách nhiệm nối lại sợi quang
thay vì sợi có thể "chọn" bộ lập lịch cho một cụ thể
điểm treo. Do đó, một sợi quang sẽ được giới hạn hiệu quả trong một
Người lập kế hoạch

Tốt,
Niklas

use namespace HH\Asio;

async function async_task(): Awaitable {
  await Asio\usleep(1000000);
}

<<__EntryPoint>>
function main(): void {
  $start = microtime(true);

  $async = async {
    concurrent {
      await async_task();
      await async_task();
    };

    return 'hello';
  };

  $result = Asio\join($async);

  printf('Result: %s ( %f )', $result, microtime(true) - $start); // output "Result: hello ( 1.010382 )"
}

use namespace HH\Asio;

async function async_task(): Awaitable {
  await Asio\usleep(1000000);
}

<<__EntryPoint>>
function main(): void {
  $start = microtime(true);

  $async = async {
    concurrent {
      await async_task();
      await async_task();
    };

    return 'hello';
  };

  $result = Asio\join($async);

  printf('Result: %s ( %f )', $result, microtime(true) - $start); // output "Result: hello ( 1.010382 )"
}

use namespace HH\Asio;

async function async_task(): Awaitable {
  await Asio\usleep(1000000);
}

<<__EntryPoint>>
function main(): void {
  $start = microtime(true);

  $async = async {
    concurrent {
      await async_task();
      await async_task();
    };

    return 'hello';
  };

  $result = Asio\join($async);

  printf('Result: %s ( %f )', $result, microtime(true) - $start); // output "Result: hello ( 1.010382 )"
}

chưa đọc

Tôi muốn mở bỏ phiếu cho RFC này vào khoảng đầu tháng 3, vì vậy vui lòng xem lại API tối thiểu và sớm cung cấp bất kỳ phản hồi nào

Loại bỏ bộ lập lịch trình có thể là một kế hoạch tốt, nhưng xin vui lòng
xem xét lại phạm vi tương lai của bạn

Sẽ là một nỗi đau thực sự lớn để thúc đẩy mọi người sử dụng cái này
chức năng, chỉ phải viết lại nó 1 hoặc 2 năm sau vì một
cơ chế cú pháp vượt trội đã được giới thiệu

Nếu bạn có thể thêm async/await/delay/defer, ngay cả khi nó mất một
tháng hoặc lâu hơn, điều đó có thể làm cho RFC này lớn hơn đáng kể
và tác động có lợi hơn đối với người dùng

Đánh dấu Randall

chưa đọc

Tôi muốn mở bỏ phiếu cho RFC này vào khoảng đầu tháng 3, vì vậy vui lòng xem lại API tối thiểu và sớm cung cấp bất kỳ phản hồi nào

Loại bỏ bộ lập lịch có thể là một kế hoạch tốt, nhưng xin vui lòng xem xét lại phạm vi tương lai của bạn

Sẽ là một nỗi đau thực sự lớn khi thúc đẩy mọi người sử dụng chức năng này, chỉ để viết lại nó 1 hoặc 2 năm sau vì một cơ chế cú pháp vượt trội hơn rất nhiều đã được giới thiệu

Nếu bạn có thể thêm async/await/delay/defer, ngay cả khi phải mất thêm một tháng nữa, điều đó có thể khiến RFC này có tác động lớn hơn và có lợi hơn đáng kể đối với vùng người dùng

Đánh dấu Randall

--

Để hủy đăng ký, hãy truy cập. https. //www. php. mạng/hủy đăng ký. php

Chào Mark,

API sợi quang chỉ liên quan trực tiếp đến async/await, v.v. Thêm một tính năng như vậy là một đề xuất lớn hơn nhiều và sẽ không phải là một công việc nhỏ. Phạm vi tương lai đề xuất sử dụng sợi trong triển khai async/await, nhưng async/await sẽ không thay thế sợi

API sợi quang sẽ xung đột hoặc ngăn async/await được thêm vào PHP trong tương lai. Hai API có thể cùng tồn tại và phục vụ các mục đích khác nhau

Chúc mừng,
Aaron Piotrowski