Jako člověk, co pracuje s producenty typu "burzovní informace" nejsem s řešením pozastavení producenta moc spokojen
Go mimochodem hodí výjimku, vyzkoušeno (nebo možná chybu, nezkoušel jsem, jestli se dá zachytit)
Zastavování producera může vést k deadlocku. Například pokud je ta fronta oboustraná tedy ten vztah je symetrický a obě strany se přeplní. Takový pattern request-response, kdy requester vygeneruje tolik requestů, že zaplní request frontu zatímco responder zaplní response frontu. Pak requester místo aby vybíral respond frontu je bloklý na request frontě, která je plná. Znám moc dobře tyhle bolestivé situace z praxe.
Ale k tomu se možná spíš hodí publisher-subscriber, který tohle má řešeno různou formou, například přeskočením fronty na její top, nebo přeskakování na konci, když už subscriber (což je role konzumenta) nestíhá a fronta se mu pod rukama maže, začne přeskakovat data. Tohle si lze samozřejmě v nějakém option vybrat přímo na subscriberovi, s tím, že jedna z options je samozřejmě vyhození výjimky na straně subscribera, když nestíhý - aniž bych ovlivnil publishera.
Zpomalování producera/publishera nechci řešit na téhle základní úrovni, mimochodem by to znamenalo další frontu čekajících korutin, další signalizační mechanismus, další komplikace jinak jednoduchého kódu. Pokud to někdo potřebuje, ať si to podědí, a doimplementuje si to. Asi není těžký udělata awaitable operaci push, awaitera k tomu určenému a mechanismus probouzení čekající producerů, jakmile někdo udělá pop().
Intenzivně se zabývám programováním zejména v jazyce C++. Vyvíjím vlastní knihovny, vzory, techniky, používám šablony, to vše proto, aby se mi usnadnil život při návrhu aplikací. Pracoval jsem jako programátor ve společnosti Seznam.cz. Nyní jsem se usadil v jednom startupu, kde vyvíjím serverové komponenty a informační systémy v C++
Přečteno 50 690×
Přečteno 23 715×
Přečteno 22 754×
Přečteno 20 740×
Přečteno 17 637×