GIL е опционален в питон от около година. Дали ще пишеш с изключен GIL асинхронно в питон няма да се отрази на еднонишковия event loop, освен ако не създаваш нови ивент loops които да вървят в отделни нишки експлицитно, но то това и с GIL включен беше възможно(доколкото GIL-a позволява)
Смятаййй, имаме вече професори по нещо наречено "питон", трололоолол.
Сички са му криви на тоз таласъм.
Освен ако не са открили стрелящи 5г часовници - ще приключи като всеки правоверен инокулиран идиократ. До тогаз ще ни радва с приказки как познавал лично Били белезниците. Може да е купил ниви до тях, изкупи половин фащ.
Аз съм КОНСУЛТАНТ. Разни като тръбата са ми клиенти.
Тия скумуват в левитация. Като космонавти. Ганорникът има песенки за тях.
Цели дни са ми губили.
Това дали ще се "изпълнява едновременно" няма никакво значение защото в тоя конкретен случай (заявка към база данни) нищо не се изпълнява (на този компютър дето await-ва). Просто се чака. В тоя смисъл е същото като в Python. C# може да ползва async/await механизма за изчакване на истинска работа на друга нишка, което Python май не може (ако може сигурно е от последната версия дето махнаха GIL), но това в тоя случай е ирелевантно.
И пак да кажа - старото онзи код щеше да ги напише с мазни await-и на всяка задача преди да се пусне следващата. Да, въпросният http request ще мине по-бавно, голям праз, но от scalability гледна точка намаляваш риска някой да трябва да чака дълго за сметка на друг, правиш откриването на проблеми по-лесно и ако случайно някой ден смениш начина по който достъпваш базата няма риск да трябва да минаваш навсякъде щото се оказало, че новият ти data access начин не поддържа паралелни заявки (да, EF баш така прави, или поне правеше, така и не разбрах дали го оправиха това специално когато ползваш един Context обект)
акаунт
на
Единия Създадено на 04.11.2024, видяно: 138 пъти. #125570
Недей бе Синджирка - и аз бех "кон-султан" у време оно.
Обясни на плоскоземците, ко праиш...
От всичките неща които джонката ги говори за GC, вярно е само това, че по-агресивно захапва памет. Май щото така може да си мете на едно място докато си пише на друго. По принцип винаги има stop the world проблем ама в съвременните GC-та той е много рядък и относително кратък, по-рядък отколкото да ти хлъцне мрежата или базата така че на практика е без значение, аз толкова години един път не съм имал проблем дето да се е оказал от GC. В същото време GC е много добър в най-важната метрика за web - throughput. Има някаква истина в това, че десктоп програмите на Java, C# и JS са по-лагави от тея на C/C++, но в наши дни това не се дължи на технологията, а на факта, че C++ програмистите са свикнали да се борят за всяко парче производителност, а сървърните програмисти дето бичим GC езиците не, поне не по този начин и съответно като си докараме практиките които не пречат на сървърите с много гигабайти рам в десктоп програмите те стават по-лагави. Разбира се има и контрапримери ей така да се докаже, че не е от езика.
Стилгарски, ти явно не си писал програми де генерират милиарди обекти да видиш тогава е ли проблем метенето на .нет буклука или не е.
Тъй като sql не е добър за аритметика която зависи от сметката на предния ред - например баланс на счетоводна или банкова сметка - дата, взел, дал, налично - реших да направя бизнес логиката на .нет вместо да я чупя на две между сторед процедури и остро си. И сега сметни един супермаркет който в час пик продава хиляди стоки. След това го репликирай между всички обекти за голяма верига магазини. И покажи справка коя стока каква наличност има в момента по отделни обекти или колко е печалбата по часове/райони/ група стоки. Като всичкото това го смяташ на остро си с орм на практика се генерират милярди обекти с много кратък живот и съответно фрагментацията и консумацията на памет са мудовищни. Метенето на боклука блокира всичко понякога за 2-3 минути - и през това време имаш няколко опашки с бързащи рабиняци дето псуват тея компютри и системи.
Аз си знам грешките и втори път не бих ги направил, но все се надявах, че тез момци от цлр екипа знаят какво правят и нещата макар и бавно ще работят. Спирането на въртенето на земята ми дойде в повечко.
Втората заявка няма да бъде пусната в питон, пускането на заявката към базата е това дето се изпълнява на локалния компютър. В питон този код ще мине последователно, първо ще се пусне заявката към базата за броене, ще се изчака резултата и чак след това ще се стартира заявката за извличане на записите:
async def fetch_count():
...
return 10
async def fetch_records():
...
return records_list
async def run():
t1 = fetch_count()
t2 = fetch_records()
await t1
await t2
A в този код, ще се пусне заявката за броене, докато се чака отговор ще се пусне заявката за извличане на записите.
async def fetch_count():
...
return 10
async def fetch_records():
...
return records_list`
async def run():
t1 = fetch_count()
t2 = fetch_records()
await asyncio.gather(t1, t2)
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| image.png | 35504 bytes | 04.11.2024 | 35 | 66e7d304693a90045877b409945817c6 |
Според мен или си писал с краката си или информацията ти е от 2003. Точно пък обектите с кратък живот не са проблем на практика. Виждал съм проблем с дебели масиви и огромни стрингове дето отиват на large object heap ама дори за това дадоха вече контрол (вярно, ръчен). Да не говорим освен всичко това колко инструменти има за да избягаш от алокациите, които даже не ми се е налагало да ползвам (разбира се фреймуъркът ги ползва за мен вътрешно), то array pool, то span (това признавам съм го ползвал ама не щото ми е трябвало ми така, да се чувствам готин като C програмист), то memory<t>...
Урсулопитешкия лумпен не е виждал нещо повече от С. Инак традиционнното самочувствие на мисионера, живее в най-оригиналното гето, режат им ушите със Солинген 
Не беше писано с краката. Просто беше развитие на предния ми продукт на ц/ц++ към дот нет. Говоря за периода 2003-2008. Както казах имах достатъчно време да анализирам къде съм сбъркал - много грешки направих но това не прави дот нетя добър метач него време.
Транзакции на каса не са драстично натоварване, неко Гана е правила обратно наддаване при наемането, и затуй така.
Губили сме грамадни клиенти, зарад подобни неща. Жуняци творили тотално мазало, и айде наемат senior на 1/5 ставка чистачка, и да оправя.
хммм това какво ще даде
ако имаш
async def test()
print('hello')
await asyncio.sleep(5)
print('world')
и го викнеш какво ще стане?
Иначе документацията говори за някакво create_task дето трябва да се ползва та май си прав и поведението на C# ще се получи ако се ползва това create_task
Доста енергия изхабихте за няма нищо. Програмните методики са широко множество и няма особен смисъл да се спори кой е крив и кой е прав. Писал съм управител на паметта, който работи по най-простия възможен начин - всеки програмен процес преди смъртта си изтрива заетата от него памет. И това ми върши отлична работа, макар, че някой теоретик може да намери кусур на такъв начин. Аз го харесвам, защото е лесен за наблюдение и прост за реализация. Но забраната на свободен достъп до паметта, струва ми се, е малко по-различна задача, свързана с едновременната работа на процеси. Лично на мен ми изглежда като "забрана за свободно програмиране", което е в тон с глобалната полицейщина в IT сектора.
Некадърния "консултант", типично по консултантски, се е оплел в кълчищата и дори и ChatGPT не може да му помогне.
В което няма нищо лошо, ако имаше способността да си признае когато е некадърен.
За GC дори няма смисъл да се говори с хора, които не знаят колко добри са съвременните GC. Разни думички като multi-generational, asynchronous и т.н. не им говорят нищо.
Нищо няма да стане, докато не го awaitnesh или не го вкараш в event loop-a.
Ще се получи подобно, но не същото. В C# асинхронния таск ще тръгне паралелно на кода който го е стартирал, в питон трябва event loop-a да се освободи, потенциално от последващ await в кода(не задължително върхъ таска) след този който го е стартирал, и това не е заради GIL-a сам по себе си, а заради имплементацията в питон, която естествено е повлияна от наличието на GIL.
import asyncio
import time
async def some_task():
print("Task started")
await asyncio.sleep(2)
print("Task completed")
async def main():
task = asyncio.create_task(some_task()) # Task is created but won't start immediately
print("Main function continues immediately without yielding")
while True:
sleep(1) # This prevents the task from running indefinitely
await asyncio.sleep(2) # Now the task gets a chance to run OR
await task # Now the task gets a chance to run
asyncio.run(main())