[Проект] Визуализация на goroutine-и и тяхната комуникация

1. Go има много приятен concurrency модел и мисля, че може да стане още по-приятен за употреба, ако можем да виждаме графично каква комуникация се случва. Затова и следната идея:

   Command line tool, който минава през проекта, вижда кои функции са "анотирани", че искаме да ги изследваме, и създава копие на проекта, което като пуснем, започва да праща в реално време (към някакъв front-end) какви съобщения се пращат по канали между тия горутини.

   • За целта стигнах до извода, че изглежда ще трябва да променям кода около четене/пращане от канали в отбелязаните за изследване функции.
   • Също така мисля, че ще трябва да използвам и генериране на код, заради липсата на generics в Go.
   • Front-end-а мисля да бъде някакъв JavaScript (или евентуално нещо, което се компилира до него, като CoffeScript или по-скоро ClojureScript). Но няма да се фокусирам много върху тази част - все пак курса е по Go :)
   • Мисля тази визуализация да може да работи в 2 режима: единият е нормалния режим, който показва съобщенията както се случват реално, а другият режим налага bottle-neck на съобщенията, така че да има само по едно единствено пращане в конкретен момент. (За тази част имам леки притеснения, че е възможно това да счупи проекта в някакви ситуации, макар и да не успях да измисля такава. Има ли случай, в който се налага едновременното пращане на 2 събощения, за да не стане dead-lock?)
   • Трябва да може да се променя като параметър времето, за което се показва едно изпратено съобщение.
   • А би било хубаво и ако може да се усеща, когато канала е буфериран и да показва цялото queue от стойности.

   Публикувано преди над 2 години

2. Съгласен .

   Забележки/Въпроси:

   1. Силно ти препоръчвам да пишеш на errout подобно на всички други tool-ове. И съответно нещо да ги чета от там и да ги виолизира/препраща и така нататък. Така също ще може лесно да си изпълниш програмата и после да я визиолизираш множество пъти.
   2. Предполагам че си видял че в godebug правят часта с генерирането на код, както и във go tool cover.
   3. Нещо не разбрах часта за двата режима. Смяташ че не можеш да пратиш две съобщения едновременно? Смяташ че ще е тежко?

   Публикувано преди над 2 години
3. 1. Realtime комуникация между програми с файл? Това добра идея ли е? Аз мислех за нещо като gRPC, но може би е overkill.
   2. Гледах go generate и gen. За godebug не знаех, ще го разгледам.
   3. Идеята за втория режим е, че потребителя може да предпочита да вижда едно по едно пращанията за да не му се налага да следи няколко неща едновременно. Става въпрос за UI concern. А ако реша да го имплементирам този 2ри режим се чудя (вече технически concern) дали това изкуствено налагане да се праща само по един канал във даден момент може да причини deadlock например.

   Публикувано преди над 2 години
4. 1. Пояснявам си предложението: Имай две части - една която пише какво се случва, и една която го парсва и прави нещо. Едната част ще пише(подобно на всички други такива тулове) на стандартния изход за грешка. Той може и да се пайпне към друг процес може и към файл. Втората част визиолизира изхода от първата. По този начин може да си пазиш изхода от първата и да си ги реплейваш във втората колкото искаш. Или да ги пайпваш и да ги гледаш в "реално време".
   2. Ти по скоро ще трябва да пренаписваш кода отколкото да ползваш go generate или gen. Това го правят godebug и go tool cover. Както предполагам си погледнал и двата тула се викат подобно на go build/run, но вместо просто да компилират първо малко преправят кода. По този начин някой който ти ползва тула трябва да прави минимални(или даже никакви ако измислиш как) промени по своя код.
   3. Това по скоро бих горе решил с буфериране вместо с това двете части да са толкова силно свързани. Към текущия момент не мога да се сетя как би се получил deadlock, но определено ще забавя изкуствено изпълнението на програмата.

   Публикувано преди над 2 години

Трябва да сте влезли в системата, за да може да отговаряте на теми.