🧩 Хитрая задача по Go — «Пул, который не течёт, не зависает и сохраняет порядок»

Задача:
Реализуй обобщённую функцию MapOrdered — ограниченный по параллелизму пул воркеров, который применяет функцию fn к входным элементам и отдаёт результаты строго в порядке входа, при этом:
- не теряет отмену context.Context,
- не допускает утечек горутин и зависаний,
- корректно обрабатывает panic внутри fn,
- поддерживает «раннее завершение» (как только достаточно результатов),
- обеспечивает backpressure (не раздувает буферы).

Сигнатуры:

type Result[R any] struct {
    Value R
    Err   error
}

type Options struct {
    Workers       int           // >0, число воркеров
    MaxInFlight   int           // ≥ Workers, ограничение внутренних буферов
    EarlyStopN    int           // если >0, остановиться после N успешных результатов
    PanicAsError  bool          // если true, паники маппятся в error
    TaskTimeout   time.Duration // если >0, дедлайн на одну задачу
}

func MapOrdered[T any, R any](
    ctx context.Context,
    input <-chan T,
    fn func(context.Context, T) (R, error),
    opt Options,
) <-chan Result[R]

Требования и тонкости

- Строгий порядок.
Выходные элементы должны соответствовать порядку поступления во input. Параллелизм допустим, но публикация результата — строго по индексу.
- Отмена и завершение.
- При отмене ctx функция должна без утечек завершить все горутины и закрыть выходной канал.
- Если EarlyStopN > 0, как только выдали N успешных результатов — корректно останавливаем обработку оставшихся задач (не зависаем, не «подвешиваем» воркеров).

🟠Backpressure.
Никаких неограниченных буферов. Учитывай MaxInFlight, чтобы не переполнять память при медленном fn.

🟠Panic-handling.
Если PanicAsError=true, паники из fn перехватываются и превращаются в error. Если false — паника должна «пробить» наружу (но без гонок и утечек).

🟠Timeout на задачу.
При TaskTimeout>0 каждая задача исполняется с отдельным контекстом-дедлайном; таймаут — это ошибка задачи, а не общий стоп пула.

🟠Гарантия отсутствия утечек.
После закрытия input и/или отмены контекста пул завершает все свои горутины. Проверь runtime.NumGoroutine() до/после и убедись в стабильном числе.

🟠Без гонок.
Решение обязано проходить -race.

🟠Zero-copy по возможности.
Не копируй большие данные лишний раз; не «складывай» всё в память — обрабатывай потоково. Допустимы минимальные накладные структуры (индексы, слоты).

Подсказки (но не решение)

- Для сохранения порядка пригодится «кольцо результатов» или слайс «слотов» с публикацией по индексу и «ползунком» выдачи.
- Отдельно продумай: кто закрывает выходной канал и когда (все задачи обработаны, или ранний стоп).
- Аккуратно обращайся с контекстами: каждому fn — свой дочерний ctx (для таймаутов), общий ctx — для остановки пула.
- Не забудь про range-variable capture в горутинах.
- Паники оборачивай через recover, если включён PanicAsError.

🧩 Go: как работает errors.As с указателями и значениями

Ниже — мини-пример, который показывает, почему иногда нужно передавать &ptr, а иногда — сам ptr. Главное правило: errors.As(err, target) принимает указатель на тип (или интерфейс), и сопоставление происходит по типу элемента этого указателя.

Код:

package main

import "errors"

type E struct{}
func (E) Error() string { return "" }

func main() {
 e := &E{}
 println(
  errors.As(*e, &e), // err:   E,   target: **E  -> ищем *E в цепочке, но у нас E
  errors.As(*e, e),  // err:   E,   target: *E   -> элемент target = E, совпало
  errors.As(e, e),   // err:  *E,   target: *E   -> элемент target = E, не совпало
  errors.As(e, &e),  // err:  *E,   target: **E  -> элемент target = *E, совпало
 )
}

Ожидаемый вывод:

false true false true

Ключевая идея:

🟢Если в err лежит значение типа E, то для совпадения target должен быть *E (элемент указателя — E).
🟢Если в err лежит *E, то для совпадения target должен быть **E (элемент указателя — *E).
🟢Шаблон «поймать конкретный тип ошибки-пойнтер» обычно выглядит так:
var te *T; if errors.As(err, &te) { ... } — именно двойной указатель в target.