[Перевод] Программист-4chan'овец

Введение

Мы используем Go для создания Dolt, первая в мире БД SQL с контролем версий. Как и большинство кодовых баз, основанных Go, мы используем каналы и горутины (от переводчика, автора этой статьи на Хабре: у меня есть хорошая статья на тему параллелизма в Go) для реализации параллелизма. Как правило мы используем эти конструкции очень скучным и обычным путем, ведь параллелизм и так сложен без всяких выдумок. Но в одном месте мы все-таки взяли маленький кусочек кода из другого open-source проекта, который использует каналы очень интересным способом: канал используется для отправки другого канала:

var c chan chan struct{}

Это канал, который отправляет другой канал, который отправляет структуру. По факту, это способ передачи каналов между разными горутинами, чтобы реализовать паттерн fan-out Думайте о «центральном» канале как о посреднике в рабочем процессе: его работа заключается в том, что бы передавать новые каналы по мере их поступления вплоть до рабочих, которые выполняют с ними реальную работу. Это работало, но идея была чересчур спецефична, с которой было трудно работать, учитывая утечки горутин. Мы переписали это, но chan chan struct{} исчезло.

Эта идея заставила меня подумать. Насколько далеко можно зайти в этой глупой идее? Узрите то, чего не ожидали, но за чем пришли. 4-chan:

_4chan := make(chan chan chan chan int)

Зачем это

Это старая шутка из времен, когда C и подобные доминировали. Много людей долгое время не могли понять принцип указателей (pointers), наверное потому, что у них не было этого мема:

d8e5d2b09c37442dee62107030863275.png

Из-за того, что указатели были сложны для понимания многим людям, а использовались они для важных и полезных вещей в C, новички иногда делали довольно глупые вещи, например: объявляли переменные следующим образом:

int****

Эти новички не понимали, какую глупость они делают, считая это признаком опыта. Таких несчастных называли »4-звездочными программистами»(4-star programmers).

Так как Go тоже поддерживает указатели, у Вас есть возможность сделать такую же вещь:

func main() {	i := 1	setInt(&i)	fmt.Printf("переменная i равна %d", i)
}
func setInt(i *int) {	setInt2(&i)
}
func setInt2(i **int) {	setInt3(&i)
}
func setInt3(i ***int) {	setInt4(&i)
}
func setInt4(i ****int) {	****i = 100
}

После запуска эта программа выведет переменная i равна 100. Вы тоже можете быть 4-звездочным программистом, это не сложно.

Но мы можем зайти дальше и использовать конструкцию, которая есть в Go, но которой нет в C: каналы. В коде они обозначены как chan.

737af51ecee16b4bec5775a9c7cce79b.png

Понимаете к чему я веду?

Программист 4-chan’овец

Идея заключается в том, что мы будем использовать 4 слоя канала для выполнения какой-то задачи. Наш верхний уровень канала будет четвертым, поэтому обозначать его будем так:

_4chan := make(chan chan chan chan int)

(тут немного раздражает то, что Go не разрешает начинать переменные с цифры, но ничего не поделаешь, такова жизнь).

Данные, которые будем посылать в этот канал будут выглядеть так:

_3chan := make(chan chan chan int)

А в этот канал будем отправлять _2chan и так далее до самого конца, где будем записывать int.

На каждом слое обращения к другому каналу будем создавать продьюсеров (producers) по некоторому постоянному фактору factor. У нас это будет const factor = 3:

func sendChanChanChan(c chan chan chan chan int) {	for range factor {		go func() {			logrus.Debug("стартую 3chan producer")			_3chan := make(chan chan chan int)			sendChanChan(c, _3chan)		}()	}
}

И похожее для консюмеров (consumers):

 func receiveChanChanChan(c chan chan chan chan int) {	for _3chan := range c {		logrus.Debug("получено сообщение с 4chan")		for range factor {			logrus.Debug("стартую 3chan consumer")			go receiveChanChan(_3chan)		}	}
}

Продолжаем дальше:

func sendChanChan(_4chan chan chan chan chan int, _3chan chan chan chan int) {	_4chan <- _3chan	for range factor {		go func() {			logrus.Debug("стартую 2chan producer")			_2chan := make(chan chan int)			sendChan(_3chan, _2chan)		}()	}
}

И по такому принципу до sendChan и receiveChan.

В самом конце очереди мы высылаем фактическое значение, а не еще один канал. К этой функции (send) будем обращаться из sendChan():

func send(_2chan chan chan int, _1chan chan int) {	_2chan <- _1chan	for range factor {		go func() {			logrus.Debug("стартую int producer")			for range factor {				go func() {					logrus.Debug("отправляю число")					_1chan <- 1				}()			}		}()	}
}

Для консюмеров (consumers) мы должны что-то сделать с данными, которые получили в каналы. Давайте их сложим.

func receive(c chan int) {	for s := range c {		logrus.Debug("получено число")		sum.Add(int32(s))	}
}

Теперь все это объединим:


const factor = 3
var sum = &atomic.Int32{}
func main() {	// logrus.SetLevel(logrus.DebugLevel)	_4chan := make(chan chan chan chan int)	go sendChanChanChan(_4chan)	go receiveChanChanChan(_4chan)	time.Sleep(500 * time.Millisecond)	fmt.Printf("%d ^ 5: %d", factor, sum.Load())
}

Эта программа печатает 3 ^ 5: 243. Все правильно! Она представляет собой обобщенный способ вычисления пятой степени числа максимально распределенным способом. Вы можете потыкать это здесь (или посмотреть с подсветкой синтаксиса тут). Для более крупных факторов Вам может потребоваться увеличить длительность «засыпания» в функции time.Sleep().

Если Вы включите логгирование (раскомментировав первую строку в main), Вы получите примерно такой вывод, что помогает посмотреть на все слои каналов:

      стартую 3chan producer      стартую 2chan producer      стартую 3chan consumer      стартую 2chan consumer      стартую chan producer      стартую 1chan consumer      стартую int producer      получено число      отправляю число

Комментарий к этому всему

Есть много причин не делать этого в реальном коде: сложность реализации и отладки, наличие небольшого самоуважения, нежелание быть забитым до смерти клавиатурами Ваших коллег и т.д.

С другой стороны, это весело делать и забавно осознавать, что это вообще работает.

Одна из лучших практических причин не отправлять каналы по каналам заключается в том, что это действительно затрудняет закрытие любого из них, что, очевидно, Вы хотели бы сделать в реальном коде, верно? В какой-то момент я фактически реализовал логику закрытия, что потребовало добавления sync.WaitGroup буквально везде, чтобы я мог отслеживать, когда все отправленные каналы были завершены для их закрытия, но остановился на time.Sleep().

Habrahabr.ru прочитано 712 раз