Публикувано е трето предизвикателство. Можете да задавате въпросите си в тази тема.
Трето предизвикателство
Не е нужно да се грижим за затварянето на каналите както и нашия Broadcaster не е нужно да има механизъм за спиране нали ?
Не, не е нужно да се грижите за затварянето на каналите и не е нужно да имате механизъм за спиране.
Имам въпрос относно условието. В него се казва "При извикването на метода Register(), да се регистрира нов слушател и да се връща канал за получаване на съобщенията (еднопосочен)." Към края на условието обаче се казва "Ако слушател изпрати съобщение, то е нормално той да получи своето си съобщение."
Тези две изречения не си ли противоричат - да пращаме съобщение по еднопосочен канал за четене ?
@Йосиф, няма да се изпраща по еднопосочния канал. Под "слушател" във второто изречение, което си цитирал се има в предвид - тази goroutine-а, в която си "регистрирал" слушател. Не е нещо, което ще тестваме, просто не искаме да се опитвате да правите някакви магии и да се чудите как да изключвате някой от "broadcast групата". Всеки изпраща през
b.Send().Някой да знае защо като напиша функциите от предизвикателството и изпълня тестовете получавам:
runtime.main: call to external function main.main runtime.main: undefined: main.maiНямам main функция в решението
Не знам за останалите, но за мен това предизвикателство се оказа по-трудно от всички останали предизвикателства и всички задачи, взети заедно
-> 
-> 
-> -> 
-> 
И при мен е така, мисля, че ни трябва още една лекция за конкурентност?
Ок, така да бъде. Ще обърнем повече внимание след теста.
Може ли да качите версия на някой от екипа на предизвикателството или поне да кажете на кого от предалите е най-добре като пример за тези горутини? :)
@Цветелина, не знам до колко ще е ползено, но малко след предизвикатеството написах три различни решения (малко по генерални, а не просто за цели числа) и им пуснах по няколко benchmark теста: линк
SyncBroadcasterе най-тривиалното решение, което би блокирало, ако някой слушател не получи съобщението в даден момент.AsyncBroadcasterе почти катоSyncBroadcaster, но няма да блокира, а ще пусне разпращането в отделна горутина.LinkedBroadcasterе съсвсем различен подход за решаване на проблема и лично на мен ми хареса как се получи, но очевидно не работи добре на 1 процес.Не съм имплементирал решението на Киро от часовете. Според мен то ще се представи малко по-зле от
AsyncBroadcaster, но има допълнително ниво на сигурност, че няма някой да си затвори канала (в другите имплементации не се връща канал за писане, а съобщението се подава като аргумент на метод, така че това няма да е проблем).Като цяло всяко решение си има плюсове и минуси. Ще се опитаме скоро да пуснем тестовете на предизвикателството, за да видите как сте се справили вие.
Благодаря :)
Всъщност би ми харесало да се съберем и да напишем нещо с конкурентност, го рутини и т.н., тоест да имаме нещо като практическо занимание по темата до края на курса. Според мен това е ценното в езика и може би крайъгълен камък в проектите на някои хора. Не знам дали колегите ще ме подкрепят.
Трябва да сте влезли в системата, за да може да отговаряте на теми.