Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Google начал открытие реализации модели потоков M:N"	+/–
Сообщение от opennews (??), 28-Июл-20, 13:03
Компания Google предложила для включения в состав ядра Linux первый набор патчей с реализацией компонентов, необходимых для обеспечения работы модели потоков M:N. Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра Linux, обеспечивающего работу реализованной в пространстве пользователя многопоточной подсистемы, применяющей модель потоков M:N.  Подсистема используется в Google для обеспечения работы сервисов, требующих минимальных задержек. Планирование и управление распределением потоков производится целиком в пространстве пользователя, что позволяет существенно снизить число операций переключения контекста за счёт минимизации выполнения системных вызовов... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53443
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 28-Июл-20, 13:03	+2 +/–
Интересно кто первый угробит линукс - гугл или микрософт?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #26, #152

2. Сообщение от Аноним (2), 28-Июл-20, 13:04	+15 +/–
Стараниями таких помощников типа мс и гугля скоро переключение контекста будет происходить через http-запрос к центральному серверу (switchto.googleapis.com)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14, #27

3. Сообщение от Аноним (2), 28-Июл-20, 13:05	–1 +/–
> Ценой данного варианта является большое усложнение реализации планировщика потоков в пространстве пользователя и необходимость в механизмах согласования действий с планировщиком ядра. Всё начинается как с системд -- сматрите, всё в разы быстрее!!11
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от m.makhno (ok), 28-Июл-20, 13:11	+/–
1:1 вроде очень лаконичная модель, зачем мудрить?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

5. Сообщение от Аноним (5), 28-Июл-20, 13:16	+5 +/–
Затем, что по-настоящему низкоуровневый и важный код пишется не для того чтобы программисты любовались его лаконичностью, а для машины и конечных пользователей. См. последний абзац.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #17, #29

6. Сообщение от Нанобот (ok), 28-Июл-20, 13:16	+/–
теперь линукс перестанет тормозить?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #10

7. Сообщение от Совершенно другой аноним (?), 28-Июл-20, 13:27	+5 +/–
Была попытка использования такой технологии в ядре NetBSD. Называлась Scheduler Activations (https://en.wikipedia.org/wiki/Scheduler_activations). Разработчики долго с ней боролись и в итоге забросили в пользу обычной 1:1.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #35, #58

8. Сообщение от Аноним (-), 28-Июл-20, 13:27	+57 +/–
комментаторы опеннет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #22

9. Сообщение от Аноним (9), 28-Июл-20, 13:27	+1 +/–
Сразу после того как весь софт на M:N потоки перепишут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #25

10. Сообщение от lockywolf (ok), 28-Июл-20, 13:28	+2 +/–
Будет тормозить в Н раз быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

11. Сообщение от Аноним (11), 28-Июл-20, 13:29	–6 +/–
Но "технологическое отставание" все равно у линукса. Смотри не перепутай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #18, #24, #36

12. Сообщение от null (??), 28-Июл-20, 13:32	+6 +/–
https, а не http
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #61

13. Сообщение от anonymous yet another (?), 28-Июл-20, 13:33	+42 +/–
Ага, если кто не знает истории. В своё время в Solaris была (лучшая на тот момент) релизация нитей (aka легковесный процесс). Модель была M:N. Ребята из ядерной группы, решая какую-то проблему Oracle'а для раскрутки проблемы быстренько написали компактную реализацию нитей в модели 1:1. И внезапно увидели ох^W весьма нехилый рост производительности. И потратили месяца четыре на выяснение --- где они лажанулись. Не нашли. Через четыре месяца эта модель пошла опцией в бету Solaris'а, и в следующем релизе стала основной (и единственной) моделью нитей в Solaris'е. Объяснение выигрыша более простой модели получилось такое: "радикальное упрощение планировщика позволило заниматься делом, а не планированием". В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е. Сейчас наблюдаем: - во многие языки тянут coroutines (\equiv "зелёные нити"); - G. подтягивает супер-инновационную модель M:N.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #19, #42, #54, #85, #93, #120

14. Сообщение от Аноним (14), 28-Июл-20, 13:39	+/–
Ыыы, жжошь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

15. Сообщение от user90 (?), 28-Июл-20, 13:49	+/–
Ну давайте-ка честно: гугл за последние ГОДЫ не сделал ни-че-го хорошего! Пожалуй за последние лет 10.. Поэтому, даже из общих соображений понятно, что место этому на свалке :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #39

16. Сообщение от CAE (ok), 28-Июл-20, 13:49	+3 +/–
Возможно, простая модель письма прикладнух без асинк колбэков один тред один сокет, сподвигла G. повторять достижения. IMHO, внятное письмо на M worker N сокетов с колбэками и есть по сути M:N, только в пространстве пользователя. Но тут всем лениво, это же прикладнухи писать, пахнет своим шедулингом. Поэтому и идёт попытка один раз загнать в ядро. Так думаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #32

17. Сообщение от m.makhno (ok), 28-Июл-20, 13:51	+1 +/–
насколько же велики эти накладные расходы по переключению контекста?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #20, #55

18. Сообщение от Совершенно другой аноним (?), 28-Июл-20, 13:54	+12 +/–
Э.. а я про Linux ничего плохого не сказал, и про *BSD тоже. Это был исторический экскурс. Прошу прощения, что это Вас так затронуло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

19. Сообщение от Школьник (ok), 28-Июл-20, 13:57	+12 +/–
Надо же, какие олдфаги на опеннете всё ещё сидят. Приятно удивлён :-) Во фряхе, кстати, примерно та же история была с libkse - тоже вышло, что M:N модель слишком сложная. Но зумерам из Гугла некогда читать книги и архивы email-рассылок. Ну раз так, то грабли ждут их лбы. А вообще, Соляра как ядро для своего времени была изрядно впереди планеты всей. Пока во фре боролись с giant lock и кидались фекалиями в Диллона, в Соляре синхронизация и нормальная работа SMP давно была сделана как надо. Ну и SMF, зоны, включая branded, с ограничениями ресурсов, ZFS, виртуализация сетевого стека, подключаемые плагинами планировщики, классы планирования - практически всё было сделано, и бОльшая часть сделана по-человечески и еще в то время, когда нынешние зумерки-разрабы типы данных в Си изучали. Но, как говорится, не родись красивой...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #51

20. Сообщение от Аноним (5), 28-Июл-20, 13:57	+1 +/–
Таки может новость прочитаете? Там даже большими графиками нарисовано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #28

21. Сообщение от VoDA (ok), 28-Июл-20, 14:03	+1 +/–
> Основным недостатком модели 1:1 являются большие накладные расходы на переключение контекста между ядром и пространством пользователя. А куда уйдут эти расходы при M:N? Как компенсируются расходы при переносе клиентского процесса из одного ядра CPU на другое? При 1:1 и N:1 поток ядра монопольно использует память. M:N будет с разделяемой памятью, что на некоторых нагрузках может тормозить. M:N нужен для частных случаев. M:N в user space еще более частный случай.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #95

22. Сообщение от Аноним (22), 28-Июл-20, 14:06	+9 +/–
Но ведь комментаторы никакой работы, кроме комментариев не производят. Линуксу нечего бояться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #47, #141

23. Сообщение от товарищ майор (?), 28-Июл-20, 14:09	+/–
Ну зачем вы так? magic lantern вот неплохо получилась, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

24. Сообщение от Анонас (?), 28-Июл-20, 14:10	+6 +/–
2003: в NetBSD появляются Scheduler Activation 2008: переписывают поддержку Scheduler Activation для совместимости с 1:1 2020: "Google начал открытие реализации модели потоков M:N" для Linux Действительно, кто же тут отстающий?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

25. Сообщение от Дегенератор (ok), 28-Июл-20, 14:12	+1 +/–
конечно же на Расте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #37, #153

26. Сообщение от Тот_Самый_Анонимус (?), 28-Июл-20, 14:13	+5 +/–
Либерасты угробят. Ведь M:N — это зашифрованное MAN. Это явный сексизм и требуется гендерно-нейстральный термин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #30, #53

27. Сообщение от danonimous (?), 28-Июл-20, 14:14	+2 +/–
Это будет делать systemd-networkd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

28. Сообщение от annon (?), 28-Июл-20, 14:15	+2 +/–
Такие статья не пишет, как это "добро" отражается в производительности реальных многопоточных алгоритмов и какой она даёт выигрыш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #126

29. Сообщение от n00by (ok), 28-Июл-20, 14:22	+2 +/–
При этом fibers из FreeBSD выпилили, в NT их практически никто по назначению не использует, а про thread pool некоторые и не знают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #38, #49

30. Сообщение от анон (?), 28-Июл-20, 14:33	+29 +/–
>Ведь M:N — это зашифрованное MAN Master и Niger, же..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #44

31. Сообщение от siu77 (ok), 28-Июл-20, 14:40	+5 +/–
"Возьмем N точек, нет, N мало - возьмем M." (c)
Ответить | Правка | Наверх | Cообщить модератору

32. Сообщение от anonymous yet another (?), 28-Июл-20, 14:46	+3 +/–
Ввод-вывод в нитях --- это полный абзац для планировщика в userspace. Ему (user-space scheduler) будет очень удобно определять, какую из u пользовательских нитей надо будить по наличию события в-в. Ядро-то изначально такую информацию имеет: "стоим на ..., ждём события по...; случилось событие, ясно кого будить".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

34. Сообщение от Аноним (34), 28-Июл-20, 14:52	–3 +/–
Расслабьтесь. Этот код уже апробирован в голанге лет пять так что включат в ядро легко
Ответить | Правка | Наверх | Cообщить модератору

35. Сообщение от Аноним (-), 28-Июл-20, 14:54	+/–
> Была попытка использования такой технологии в ядре NetBSD. Называлась Scheduler Activations > (https://en.wikipedia.org/wiki/Scheduler_activations). Разработчики долго с ней боролись > и в итоге забросили в пользу обычной 1:1. В соплярисе и фре тоже было и тоже забросили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

36. Сообщение от Аноним (-), 28-Июл-20, 14:57	+4 +/–
> Но "технологическое отставание" все равно у линукса. Молодец, все верно подметил! https://www.freebsd.org/cgi/man.cgi?query=kse&apropos=0&sekt... > kse -- kernel support for user threads Overview      Traditionally, user threading has been implemented    in one of two ways:      either all    threads    are managed in user space and the kernel is unaware of      any threading (also known as "N to    1"), or    else separate processes    shar-      ing a common memory space are created for each thread (also known as "N      to    N").  These approaches have advantages and disadvantages:      User threading               Kernel threading      + Lightweight               - Heavyweight      + User controls scheduling           - Kernel    controls scheduling      - Syscalls    must be    wrapped           + No syscall wrapping required      - Cannot utilize multiple CPUs    + Can utilize multiple CPUs      The KSE system is a hybrid    approach that achieves the advantages of both      the user and kernel threading approaches.    The underlying philosophy of      the KSE system is to give kernel support for user threading without tak-      ing away any of the user threading    library's ability to make scheduling      decisions.     > September    10, 2002
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #101, #156

37. Сообщение от Аноним (37), 28-Июл-20, 15:04	+4 +/–
Это ж гугл. На go.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

38. Сообщение от OpenEcho (?), 28-Июл-20, 15:11	–2 +/–
Точнее сказать никто не использует в НТ-е без злого умысла, а вот вирусня помню очень даже активно юзала нитки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #41

39. Сообщение от Sarcastic scutosaurus (?), 28-Июл-20, 15:23	+/–
https://github.com/google?q=&type=source Совсем ничего, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

40. Сообщение от Аноним (40), 28-Июл-20, 15:25	+3 +/–
M:N же давно показал свою несостоятельность и выпилен отовсюду куда его пытались впилить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

41. Сообщение от n00by (ok), 28-Июл-20, 15:43	+/–
Например, волокна (fibers) применяют для реализации сопрограмм. Зловреды именно что нитки (thread) задействуют, инжектируя код в чужое адресное пространство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #118

42. Сообщение от Аноним (42), 28-Июл-20, 16:03	–6 +/–
> На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO) > - во многие языки тянут coroutines (\equiv "зелёные нити"); Да в этом все и дело - удобно реализовать сопрограммы без поддержки языка не вышло, а поскольку в божественной нерасширяемой идеальной сишечке поддержки нет, то и прижиться они не могли, а очень бы пригодились например в микроконтроллерах вместо гигантских конечных автоматов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #48, #72

43. Сообщение от Аноним (43), 28-Июл-20, 16:16	–1 +/–
>Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра Linux Зачем Гугл пихает в ядро своё говно? Пусть оно так и оставалось бы за закрытыми дверями?
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от Тот_Самый_Анонимус (?), 28-Июл-20, 16:18	+1 +/–
Ты прав, так намного очевиднее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

45. Сообщение от Аноним (45), 28-Июл-20, 16:22	+/–
Я чего то недопонял. Сначала все хипстеры у гугл в том числе тянули TCP в usermode и продвигали модели разработки свойственные микроядрам. Хвалили виртуальные машины, ядро которых по сути особое приложение. А теперь заявляют, что этот подход медленный и нужно вернуться к монолитам? Что дальше, WebAssembly в ядре вместо процессов, чтобы вообще контекст не переключать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56, #64

47. Сообщение от Satori (ok), 28-Июл-20, 16:29	+8 +/–
>Но ведь комментаторы никакой работы, кроме комментариев не производят. Линуксу нечего бояться. Даже окружающую среду не портят, в отличие от гномеров :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #123

48. Сообщение от anonymous yet another (?), 28-Июл-20, 16:33	+3 +/–
Привет поколению Z! Вы язык программирования с архитектурой процессора(ов) в запарке не попутали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #73

49. Сообщение от Аноним (51), 28-Июл-20, 16:40	+/–
Это хорошо или плохо? Объясните пожалуйста ламеру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #98

50. Сообщение от Zlo (??), 28-Июл-20, 16:44	+1 +/–
Итак создаем проблемы, добавляя фичу долго и упорно с ними боремся. Удаляем фичу красиво аргументируя графиками и цифрами которые идеально подогнаны на частных случаях. Пол года можно при этом поплевывать в потолок получая деньги. PS. Хотя хочется верить что гугл тока веб ломает, а не добрался и до линукса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

51. Сообщение от Аноним (51), 28-Июл-20, 16:46	–9 +/–
Сначала дождитесь рабочей реализации и делайте выводы. Сложно, да. И что? Это значит, что совсем нереализуемо? Нет. Если реализуют, будет быстро. Если нет, то нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #52, #78, #91

52. Сообщение от Аноним (51), 28-Июл-20, 16:48	–14 +/–
Более того, если всё будет работать как надо, это покажет некомпетентность всех предыдущих разработчиков, у которых ничего не вышло и вынуждены были забросить. Не выгораживаю гугл, но выводы рано делать однозначные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #60

53. Сообщение от Аноним (-), 28-Июл-20, 17:02	+1 +/–
> Либерасты угробят. Тоталитарные уродц придумали на этот случай отличное решение: нет софта - нет проблем! А если еще инженерию слить до уровня землянок - вообще становится зашибись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #57

54. Сообщение от rshadow (ok), 28-Июл-20, 17:03	+/–
> полная х...ь как концепция, IMO Сразу понятно что вы не программист. Но спасибо за исторический экскурс. https://ru.wikipedia.org/wiki/C10k
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #59, #62

55. Сообщение от Аноним (55), 28-Июл-20, 17:07	+5 +/–
Вы когда-нибудь видели по-настоящему большой виртуализированный астериск? 24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей ARI-стазисов и еще и внутренних AGI-подпрограмм. Может так случиться, что накладные расходы на переключение контекста приведут к полной деградации сервисов, при утилизации 20-40%. Скажем так. Если у вас 14000 переключений контекста на 1 ядро - конец близок. Добавьте накладные расходы на виртуализацию и каждый CS становится золотым! Да-да. Переключение контекстов в системе может быть основной и центральной метрикой по загрузке (не CPU%) в особых случаях! Asterisk не единственный такой, есть еще Citrix Virtual Apps and Desktops (бывшие XenApp/XenDesktop). И если службы терминалов достаточно просто горизонтально смасштабировать по какому-то принципу, то с Asterisk ситуация может быть очень разная. Просто приведу пример с *, вдруг кому-то пригодится: 1. Избавиться от лишних кодеков. У вас должен быть один кодек G711 a-law, тот который стандартизирован для РФ. 2. Если у вас есть требования на G711 μ-law или T.38 вам нужно от них избавиться по причине того, что сейчас уже 2020-й год, а факсы - остались в 20-ом. Для людей которые любят традиции и жизнь прошлым, можно поставить gateway T.38 -> e-mail а исходящие факсы запретить административно. Накрайняк, можно и наоборот замутить, но это решение крайне специфично для конкретной инфраструктуры... вообще если вы работаете в компании, которая хочет отправлять факсы в 2020-ом году, то это повод искать новую работу. 3. работа с ISDN E1 и SS7 должна производиться на отдельном железе, которое нужно притранковать. Оно же вам должно всё закодировать через g711a. 4. Избавьтесь от IAX. Мат-фильтр opennet не пропустит комментарий, если я буду объяснять, что я думаю об этом протоколе. Ограничимся тем, что оно не должно было существовать изначально. Оно порождает не только проблемы с производительностью, но и с качеством. 5. CHAN_SIP должен гореть в соседнем котле рядышком с IAX2, переход на PJSIP увеличивает реальную утилизацию на ~30-40% при том же количестве контекстов. Деградация снизится, будет расти эффективность в виду внетренней архитектуры * и как он работает с потоками. 5. Регистрация - это слабое место PJSIP. Увеличение утилизации в одном случае (звонок) даёт рост КПД, в другом случае (регистрация) выливается в рост потребления ресурсов при старте. Перезагрузка сервера с 4000 пользователей может и снова его уронить. Вынос регистрации на отдельное железо решает проблему. И совсем не обязательно, чтобы там был именно *. С этой задачей превосходнос правится kamailio. 6. AGI - это дорого и жирно. Нужно сеcть с разработчиками и пересмотреть архитектуру решения либо в сторону максимального перехода на ARI либо, если не получается, написать небольшой сервер приложений на любом языке программирования, выбросив поганые python-скрипты, заменяя их веб-сервисами (можно и на python :) 7. Когда монстр похудел, пора задуматься о виртуальном сетевом адаптере. E1000/E1000E - на помойку сразу. В идеале адаптер должен подаваться через SR-IOV. Эти виртуальные адаптеры также порождают огромные накладные расходы по контекстам. Если в арсенале нет ничего лучше vmxnet - поставьте нормальный гипервизор hyper-v или KVM. 8. Снизьте накладные расходы на виртуализацию. У вас должен быть 1 сокет с фиксированным количеством памяти без всяких поползновений. Приоритеты по частотам у каждого настраиваются по-своему. Strict NUMA вам в помощь вплоть до привязки конкретных ядер конкретных камней. 9. Дальше вы включаете мониторинг и меряете переключение контекстов сутки. Относительно ПИКОВОГО значения рассчитываете количество ядер на каждые 14000 переключений. Докидываете и продолжаете следить. > насколько же велики эти накладные расходы по переключению контекста? я видел и 470 000 CS через vmstat
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #70, #71, #110, #117, #143

56. Сообщение от Аноним (56), 28-Июл-20, 17:09	+1 +/–
> WebAssembly в ядре вместо процессов, чтобы вообще контекст не переключать? Баян, это кто-то вроде уже даже накодил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

57. Сообщение от Тот_Самый_Анонимус (?), 28-Июл-20, 17:11	–5 +/–
Во бомбит, а. Пока что по очкам либеральные негромакаки уделывают. Иди, попробуй им скажи в лицо что важны все жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #124

58. Сообщение от Нанобот (ok), 28-Июл-20, 17:12	+2 +/–
Если я правильно понимаю, в винде такое тоже есть и называется fibers (https://docs.microsoft.com/en-us/windows/win32/procthread/fi...). Появилось в хр и я ни разу не видел, чтобы это где-то использовали. Что-то мне кажется, с линуксной реализацией будет так же
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #65, #68

59. Сообщение от Anonn (?), 28-Июл-20, 17:15	–1 +/–
Зато люто плюсуют. 4 месяца не могли понять, а потом ответ оказался прост. Какая-то фантастическая история по мне. А еще, как обычно: в Гугле одни идиоты (причем, заметьте, со всего мира), все здравые ребята здесь собрались: ишь, те изобретают велосипед заново, и даже не догадались подумать об очевидной вещи как %s.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #63, #67

60. Сообщение от Аноним (60), 28-Июл-20, 17:24	+8 +/–
> Более того, если всё будет работать как надо, это покажет некомпетентность всех предыдущих разработчиков, Покажет разве что в альтернативно-фенезийной логике. Остальным покажет, что запросов и юзкейсов гугля (как и бесконечных денег) у тех реализаторов не было, как впрочем и разницу в целевом железе. > у которых ничего не вышло и вынуждены были забросить. Прекратите фантазировать. > Не выгораживаю гугл, Просто, как настоящий линуксоид, подлизываешь, надеясь на другие объедки с барского стола?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #66

61. Сообщение от Повидло19 (?), 28-Июл-20, 17:25	+/–
Вот и выросло поколение, считающее HTTPS отдельным протоколом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #116

62. Сообщение от anonymous yet another (?), 28-Июл-20, 17:30	+2 +/–
Таки да, на javascript не пишу. Ссылка-то эта к чему? Риди бога, ткните в меня реализацией C10k на setjmp/longjmp! А то так в неведении и помру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #160

63. Сообщение от Аноним (-), 28-Июл-20, 17:36	+3 +/–
> А еще, как обычно: в Гугле одни идиоты (причем, заметьте, со всего > мира), все здравые ребята здесь собрались: ишь, те изобретают велосипед заново, и даже не догадались подумать об очевидной вещи как %s. Здравые ребята реалистично не считают себя Гуглом, а свои сценарии использования - схожими с гугловскими. И основываясь на опыте предыдущих, в том числе и "академически верно" проработанных реализаций, закономерно ждут подвох для всех тех, кто не является Гуглом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

64. Сообщение от Аноним (42), 28-Июл-20, 17:36	+/–
>Сначала все хипстеры у гугл в том числе тянули TCP в usermode >Планирование и управление распределением потоков производится целиком в пространстве пользователя И продолжают тянуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

65. Сообщение от rshadow (ok), 28-Июл-20, 17:37	+1 +/–
Да, причем судя по описанию задумано нормально. Создать потоки для утилизации всех ядер и в каждом крутить свой цикл для утилизации ядра. Используется редко т.к. надо заново учится программировать на событийных машинах. Намного проще когда у тебя есть простыня последовательно выполняемого кода. Без всяких подводных камней.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

66. Сообщение от Аноним (51), 28-Июл-20, 17:38	–9 +/–
>подлизываешь Не проецируй свои фантазии на других. Это лишь альтернативное мнение, не более. Включат или нет не особо волнует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #86

67. Сообщение от anonymous yet another (?), 28-Июл-20, 17:43	+1 +/–
> 4 месяца не могли понять, а потом ответ оказался прост Ребята грамотные были. Сами и задались вопросом: "какого х...а сильно более простая реализация на характерных задачах так выиигрывает? Не упустили ли чего?". Пошли измерять/сравнивать. Потом пошло в news/ML, была публикация (ACM? --- не помню). Потом отдали приближённым, потом в пред-релиз (т.н. "модель T2"). Получилось: по практическим результатам T2 выглядела сильно лучше. В вырожденных случаях T2 не проигрывала основной модели, а в ряде практически значимых сценариев --- сильно выигрывала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

68. Сообщение от Аноним (68), 28-Июл-20, 17:55	+2 +/–
Fibers, оно же coroutines - это другое. Грубо говоря, это кооперативная многозадачность, т.е. несколько задач, выполняющиеся в *одном потоке* могут переключаться между собой. Из этого вытекают и основные болячки этого подхода, как неработающий TLS, проблемы с блокировкой потока и проблемы с отладкой. В сабже речь идёт о реальных потоках, которые благодаря FUTEX_SWAP получают возможность быстро переключаться между собой. При этом, будучи настоящими потоками, для них работают TLS, их можно блокировать и они могут выполняться параллельно, если есть такая возможность. По сути, новость вводит в заблуждение, т.к. модель потоков в Linux не меняется. Просто добавляется еще одна операция, которая позволяет повысить эффективность переключения между потоками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #151

69. Сообщение от anonymous yet another (?), 28-Июл-20, 18:05	+/–
> Создать потоки для утилизации всех ядер и в каждом крутить свой цикл для утилизации ядра. Если задача --- именно утилизировать ядро, то так, наверное, и надо. Но можно было бы и что-то полезное делать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

70. Сообщение от Meme (?), 28-Июл-20, 18:08	+4 +/–
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск? Писать программы для виртуальной машины, запихивать все эти программы в разные виртуальные машины... "Ядро виновато, оно медленно всё переключает!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #75

71. Сообщение от anonymous yet another (?), 28-Июл-20, 18:16	+/–
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск? 24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей ARI-стазисов и еще и внутренних AGI-подпрограмм. Мы видели и видим не такую слабенькую технику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #76

72. Сообщение от Аноним (72), 28-Июл-20, 18:23	+/–
В "нерасширяемой сишечке" эти твои корутины делаются на макросах препроцессора. https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #74, #84

73. Сообщение от Аноним (42), 28-Июл-20, 18:30	–1 +/–
Бумерам привет. При чем тут архитектура? Для преобразования сопрограммы в конечный автомат: http://dunkels.com/adam/pt/expansion.html нужны особые архитектуры?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #77

74. Сообщение от Аноним (42), 28-Июл-20, 18:35	–1 +/–
Я знаю, пользоваться этим невозможно. Сравни с современными async/await.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #107

75. Сообщение от Аноним (55), 28-Июл-20, 18:35	+/–
> "Ядро виновато, оно медленно всё переключает!". Это вы сказали. При чем ты ядро. Если прочитать комментарий, то станет понятно, что дело в архитектуре. Кроме того, если бы вы поизучали, что такого особенного в многопоточных мультимедийных приложениях, то поняли бы почему они подвержены проблемам переключений контекстов. Срыв покровов, на голом железе ситуация примерно похожая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #92

76. Сообщение от Аноним (55), 28-Июл-20, 18:39	–1 +/–
> Мы видели и видим не такую слабенькую технику. Это комментарий в стиле "у меня болшэ"? Ну ок, чо, держите нас в курсе. Нам всем очень интересно (на самом деле нет). Комментарий был ответом конкретному человеку на конкретный вопрос. Но вот пришел ты, опой нюхаешь цветы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #94

77. Сообщение от Аноним (77), 28-Июл-20, 18:48	+/–
Зумерок, прекращай читать инвалидов умственного труда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #80

78. Сообщение от Анончик (?), 28-Июл-20, 18:52	+/–
Лол, а железо вы в расчет не берете? Или у вас на разном железе программы и их алгоритмы работают совершенно идентично?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

79. Сообщение от Анончик (?), 28-Июл-20, 19:01	+/–
Я конечно все понимаю, но если в гошечке наклепать горутин и запустить все на одном ядре 15% производительности улетают. Вполне возможно что для гугла так лучше но явно это не для всех.
Ответить | Правка | Наверх | Cообщить модератору

80. Сообщение от Аноним (42), 28-Июл-20, 19:07	–1 +/–
Автор uIP - инвалид умственного труда? Окей, бумер. Гиганты мысли с опеннета поражают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #81, #90

81. Сообщение от Аноним (77), 28-Июл-20, 19:12	+/–
Реализация tcp/ip под микроконтроллеры - святой грааль программирования? Окей, зумер, читай кого хочешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

82. Сообщение от Consta (?), 28-Июл-20, 19:18	+/–
Вопрос имею: а вот вынос планировщика в юзерспейс - как оно концептуально с точки зрения безопасности? Какие будут мнения? И должен ли этот планировщик иметь рута или какую то, может, капабилитю будет достаточно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #103, #133, #142, #146

83. Сообщение от Аноним (83), 28-Июл-20, 19:28	+/–
Было уже в Linux'е под именем NGPT, забросили где-то в 2003, перенеся в NPTL "лучшие части". ```In 2003, IBM released the Next Generation POSIX Threads (NGPT), which offered substantial improvements over LinuxThreads. It improved support for the POSIX standard, and was notable for providing an M:N threading model in which M user-space threads are executed on N kernel threads, as opposed to Linux's traditional 1:1 model.```
Ответить | Правка | Наверх | Cообщить модератору

84. Сообщение от Аноним (86), 28-Июл-20, 19:51	+/–
> В "нерасширяемой сишечке" эти твои корутины делаются на макросах препроцессора. Ты не смотрел, что по ссылке? Или просто не едал ничего слаще морковки? > https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html > So now we have this monstrosity, let's rewrite our original code fragments using it. int decompressor(void) {     static int c, len;     crBegin;     while (1) {         c = getchar();         if (c == EOF)             break;         if (c == 0xFF) {             len = getchar();             c = getchar();             while (len--)             crReturn(c);         } else         crReturn(c);     }     crReturn(EOF);     crFinish; }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #108, #134

85. Сообщение от anonymous (??), 28-Июл-20, 19:52	–3 +/–
> В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е. Всё дело в языка. Что для сишечки бессмысленно, сложно и просто ресурсы на ветер, то для жабаскрипта естественно как дыхание. Даёшь поддержку жабаскрипта (и прочих коллбек-ориентированных языков) на уровне ядра!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #99

86. Сообщение от Аноним (86), 28-Июл-20, 19:53	+3 +/–
>>>> "Google начал открытие реализации модели потоков M:N" >>> покажет некомпетентность всех предыдущих разработчиков >> подлизываешь > Не проецируй свои фантазии на других. Это лишь альтернативное мнение, не более. Т.е. я угадал. Типичная проприетарная подстилочка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #89

87. Сообщение от Аноним (-), 28-Июл-20, 19:53	+/–
Если речь о том что под Windows называется "нити" ( Fibers ) - то когда-то на Channel9-канале Mark Russinovich (было очень очень давно это) - рассказывал что в отладка ПО с нитями было похоже на АД и не рекомендовал их использовать. Точнее проблему с ними я не помню, но что-то со общими стеками и т.п.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #88

88. Сообщение от Аноним (88), 28-Июл-20, 19:55	–1 +/–
Та нет там никаких проблем особенно если все отлажено и хорошо работает под капотом. А вот разрабтывать всякие языки вроде GOlang так для этого всякие Робы Пайки есть в Гугле =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

89. Сообщение от Аноним (89), 28-Июл-20, 20:04	–6 +/–
При чём здесь проприетарщина? Как в статье, так и в обсуждении речь про СПО. У вас везде враги вашего режима в голове мерещатся. Попейте таблеточки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #102

90. Сообщение от anonymous yet another (?), 28-Июл-20, 20:16	+4 +/–
Если я правильно понимаю, то вы всё время в сторону программирования на baremetal подмигиваете. Так это вообще здесь не причём. Нет MMU, нет кэшей, нет операционки --- нет понятия kernel space/user space. Т.е. к изначальной теме никак не относится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

91. Сообщение от Я (??), 28-Июл-20, 20:25	+/–
так погодьте.. скдя по новости гугл уже написал это всё и уже использует на своих серверах, а сейчас начали готовить патчи   для коммита всего этого в мэйнстрим ядро..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

92. Сообщение от Аноним (92), 28-Июл-20, 20:30	+/–
>Срыв покровов, на голом железе ситуация примерно похожая. нет. никто не гоняет нагруженные приложения в ритуалках. спросите хотябы у держателей серверов ммо игр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #96

93. Сообщение от funny.falcon (?), 28-Июл-20, 20:35	+/–
У всех предыдущих подходов к N:M была одна общая болезнь: работа с диска. Оно блокировало «кернельный» тред, то бишь, один из M планировщиков целиком. На обработку «пользовательских» N-1 тредов оставалось M-1 шедулеров. Соответственно, если мы имеем нагрузкой базу данных, которая общается с диском много и одновременно, то очень быстро все M шедулеров оказывались в ожидании диска, а N-M тредов оказывались не удел. Первой (из общедоступных) правильный подход реализовала Go: когда шедулер-тред встаёт в сискол, она порождает новый тред. При наличии подсистемы io_uring, все становится ещё намного проще: поход на диск перестаёт быть блокирующим. Ну и, в ядре то оно всю жизнь было асинхронным, просто не было доступного апи. Вы посмотрите презентацию, они как раз упоминают враперы над блокирующими вызовами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #100, #105

94. Сообщение от anonymous yet another (?), 28-Июл-20, 20:40	+1 +/–
Если вы имели ввиду "есть специфичные системы где очень много процессов (как единиц планирования) и переключений контекстов ядро/пользователь очень много", то это "специфичные системы"; проблема эффективных менеджеров --- попытка решать довольно специальные задачи софтом "общего назначения" (и программистами общего назначения), а если получается плохо, то будем корёжить софт "общего назначения" под спец. задачи. А для совсем сильно спец. задач и кремний спецально под эти задачи есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #97

95. Сообщение от funny.falcon (?), 28-Июл-20, 20:40	+/–
> M:N нужен для частных случаев. M:N в user space еще более частный случай. Программисты на Go, имеющие M:N  в user space уже несколько лет, смотрят на тебя с пониманием. Хотя, GUI то нормального так и нет. Android, iOS - все побоку. Так что да: backend services - это действительно частный случай. Такой маааленький частный случай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

96. Сообщение от Аноним (55), 28-Июл-20, 20:51	–1 +/–
во-первых, да такая же, но в разительно меньшей степени. во-вторых, вы живете в вымышленном мире, где все работает исключительно по инструкции, производится академический анализ архитектуры приложения и нет никакого "раз, два и в продакшн". Если бы ваш воображаемый мир был реальностью, у меня бы вообще не было заказов на исправление подобной ерунды. Реальность не только в том, что люди так делают, а еще и в том, что баран^W заказчик может иметь свои обстоятельства, которые аргументируются гуманитарно, а не технически и, вообще, выбирайтесь из своего максималисткого мира грёз. Начните хотя бы с отказа от ммо игр, честное слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

97. Сообщение от Аноним (55), 28-Июл-20, 20:56	+/–
Ага, осталось только вывод сделать из собственного же комментария. Ближе к делу!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

98. Сообщение от anonymous yet another (?), 28-Июл-20, 21:04	+1 +/–
Эти категории здесь ни при чём. Предложенное не пошло по совокупности факторов: выигрыш на характерных задачах был (если вообще был, мог быть и проигрыш) несущественным, программирование требовало более высокой квалификации/внимания/организации, сопровождение (поиск проблем, воспроизводимость, ...) усложнялось. Если про fibers (coroutins там рядом), то программирование в кооперативной многозадачности --- довольно тяжелая вещь. В смысле --- тяжело программировать/отлаживать/сопровождать. Там очень много неявных ограничений на то, как и где этим пользоваться. Компиляторы косяки программирования в этой парадигме почти не ловят. Всё ложится на людишек, а это очень ненадёжный материал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

99. Сообщение от Аноним (99), 28-Июл-20, 21:11	+4 +/–
В js вообще нет нитей - он однопоточен. Главное встрять со своим комментарием про "любимый" язык?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

100. Сообщение от anonymous yet another (?), 28-Июл-20, 21:16	+2 +/–
> Первой (из общедоступных) правильный подход реализовала Go: когда шедулер-тред встаёт в сискол, она порождает новый тред. Если это так (я не знаю), то всё просто зашибись: мы попросили новую страницу памяти, а нам в ответ пытаются добавить новую единицу планирования (со всем ворохом ресурсов, привязанных к ней, в т.ч. и с выделением тучки страниц). Идея перекликается с GC в Java.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

101. Сообщение от Аноним (-), 28-Июл-20, 21:19	+11 +/–
> September    10, 2002 Ну не особенно впечатляет... Пока линукс и фряха занимаются спором у кого длиннее... А в NetBSD уже тесты уже делали в 90-х... An Implementation of Scheduler Activations on the NetBSD Operating System http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.... There are two goals of examining the performance of the scheduler activations system. The first is determining whether the added complexity of having scheduler activations in the kernel hurts the performance of ordinary applications. The second is comparing the performance of the resulting thread system with existing thread systems to demonstrate the merits of the scheduler activations approach. The first measurements were done with the HBench-OS package from Harvard University [3] [3] A. Brown and M. Seltzer. Operating system benchmarking in the wake of lmbench: A case study of the performance of NetBSD on the Intel x86 architecture. In Proceedings of the 1997 ACM SIGETRICS Conference on Measurement and Modeling of Computer Systems, pages 214-224, ___1997___. 1997 (!) Все идеи и драфты за авторством ребят из Wasabi Systems в 90-х (сейчас этой конторы нет, но костяк кодеров остался до сих пор в NetBSD). Так что все ваши фрибсд, айбиэмы, ораклы и прочее пролетают как фанера над Парижем. а вообще.... ...scheduler activations have been implemented for research purposes in Taos [1], Mach 3.0 [2]... and adopted commercially in Digital Unix  [5] (now Compaq Tru64 Unix)... Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #104, #106

102. Сообщение от Аноним (102), 28-Июл-20, 21:31	+2 +/–
> При чём здесь проприетарщина? Как в статье, так и в обсуждении речь про СПО. В обсуждении речь о восторженном подлизывании анонимом крупному проприетарщику. > У вас везде враги вашего режима в голове мерещатся. Попейте таблеточки. Странно. Мерещатся мне, а минусомет в качестве "последнего довода" расчехлил подлизыватель. От оно чЁ, Михалыч! ЧСХ - аргументов к #60 так и не последовало, только вопли оправдывания и смузихабрабные минусики. Так держать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #111, #112

103. Сообщение от anonymous yet another (?), 28-Июл-20, 21:36	+3 +/–
Ничего личного, но это не вопрос, а набор слов из предметной области. На ответ тянула бы серия лекций из области "Теория Операционных Систем".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

104. Сообщение от Аноним (-), 28-Июл-20, 21:45	+/–
>> September    10, 2002 > Ну не особенно впечатляет... > Пока линукс и фряха занимаются спором у кого длиннее... > А в NetBSD уже тесты уже делали в 90-х... > In Proceedings of the 1997 ACM SIGETRICS Conference on Measurement and Modeling > of Computer Systems, pages 214-224, ___1997___. > 1997 (!) По ссылке не ходи, на SEE ALSO SEE ALSO      rfork(2), pthread(3), ucontext(3)      Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M.      Levy, "Scheduler activations: effective kernel support for    the user-level      management    of parallelism", ACM Press, ACM    Transactions on    Computer      Systems, Issue 1, Volume 10, pp. 53-79, February 1992. не смотри, пиши про невпечатления. > Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти > ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems... Ну-ну https://www.smalltechnews.com/archives/23495 > Netflix, which previously pushed for video streaming to reach 200Gb/s on > Intel Xeno and AMD EPYC servers, has finally managed to reach 190Gb/s and > found that AMD EPYC Naples/Rome servers have the potential to double the potential for up to twice as much as Intel.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #113

105. Сообщение от Аноним (-), 28-Июл-20, 22:28	+/–
> При наличии подсистемы io_uring, все становится ещё намного проще С уриной пока всё тоже не слава богу: "io_uring is currently like kqueue on OS X - it works with "important" file types, but it fails as generic mechanism, and there is no way to detect what will work or not, so workarounds are essentially impossible." http://lists.schmorp.de/pipermail/libev/2020q3/002879.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

106. Сообщение от Аноним (-), 28-Июл-20, 22:44	+2 +/–
> Все идеи и драфты за авторством ребят из Wasabi Systems в 90-х (сейчас этой конторы нет, но костяк кодеров остался до сих пор в NetBSD). Так что все ваши фрибсд, айбиэмы, ораклы и прочее пролетают как фанера над Парижем. Почему пролетают-то? "Костяк кодеров из Wasabi Systems" выкинул M:N из NetBSD и теперь там 1:1 как в этих ваших линуксах, фряхах и опенбзд? В чём успех-то? (местные нетбздшники что-то совсем уже поехали)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #109

107. Сообщение от Аноним (72), 28-Июл-20, 22:49	+2 +/–
Ну, тем не менее, подход Саймона Тэтхэма даёт рабочие корутины (утверждалось, что их невозможно реализовать совсем в сях, кроме как руками - я привёл контрпример). А async/await как по мне - вреден, ибо большинство смузипрогеров даже не вникает в то, как это работает. Типа, о - крутая штука для "многопоточности". А что там творится под капотом и как это реализовано (скажем, что там оно разворачивается в конечный автомат) - даже не догадываются. Реально есть кадры, которые на полном серьёзе считают, что корутины - это про мультитрединг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #125

108. Сообщение от Аноним (72), 28-Июл-20, 22:51	–2 +/–
А что? Там должен быть async/await, выблёвывающий смузи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

109. Сообщение от Аноним (-), 28-Июл-20, 23:08	+/–
> В чём успех-то? разработали, написали код, протестировали, сравнили, провели тесты... чем не успех - исчерпывающая разработка проблематики? это тоже своеобразный технологический успех. я считаю - абсолютный успех... и теперь в 2020-м году гугел что-то там открывает и тестирует... какие-то графики... ох лол... либо слоупоки, либо новомодные смузихлёбы... > что-то совсем уже поехали ой да ладно... это вы поехали... или косите мол под ничего не понимающего...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #130

110. Сообщение от Онаним (?), 28-Июл-20, 23:18	+1 +/–
Я сначала хотел откомментировать, но потом понял, что этот бесценный опыт получен не просто так: из всех возможных вариантов решения везде были выбраны ошибочные. А потом героически с результатом этого действа боролись, откуда сий опыт и взят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

111. Сообщение от Аноним (111), 28-Июл-20, 23:20	+/–
В обсуждении такого не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

112. Сообщение от Аноним (111), 28-Июл-20, 23:23	+/–
>минусомет Много чести. Таблеточки всё же пропейте. Я автор тех комментариев и поставил не более одного раза минус.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #131

113. Сообщение от Аноним (-), 28-Июл-20, 23:31	+/–
> По ссылке не ходи, на SEE ALSO > 53-79, February 1992. Баш на баш. Nathan J. Williams Wasabi Systems, Inc. nathanw@wasabisystems.com The work is based on the scheduler activations kernel interface proposed by Anderson et al. [1] for user-level control of parallelism in the presence of multiprogramming and multiprocessing. [1] Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M. Levy. Scheduler activations: Effective kernel support for the user-level management of parallelism. In Proc. 19th ACM Symposium on Operating System Principles, pages 95-109, 1991. __1991__, Карл. > не смотри, пиши про невпечатления. С годами обделались, решили перейти на другие темы? Ну что же. Netflix optimizes FreeBSD’s network stack to more than triple performance on AMD EPYC November 25, 2019 __2019__, EuroBSD 2019 conference. 2019-й, Карл. Ещё бы из будущего написали, года эдак из 2095-го. Мол смотрите какая прогрессивная FreeBSD. Если решили сменить тему и в ссылки поиграть. Ну вот рандомная ссылка в стиле "у меня всё равно больше". http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever Просто надо смириться - NetBSD технологический флагман, и из нетки годами все кому ни лень рипали идеи (линукс, фряха, опёнок и тп). NetBSD тестовый, академический полигон. Тут нет ничего необычного... Про крутые программисты там сидят и пишут для души... А этот ваш продакшн утаскивает идейки из нетки, обкатывает их... ps а вообще конечно обидно за фряху... раньше была популярной системой, а сейчас зайдёшь в темы про фряху и видишь этот вечный пример про нетфликс или zfs... убогая __нищета__ аргументов, как говорится...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #114, #115, #121, #127, #128

114. Сообщение от Аноним (102), 28-Июл-20, 23:54	+1 +/–
> __1991__, Карл. >> не смотри, пиши про невпечатления. > С годами обделались, решили перейти на другие темы? Ну что же. Сам что-то придумал, сам что-то доказал. > Netflix optimizes FreeBSD’s network stack to more than triple performance on AMD > EPYC > November 25, 2019 > __2019__, EuroBSD 2019 conference. > 2019-й, Карл. Ещё бы из будущего написали, года эдак из 2095-го. Мол > смотрите какая прогрессивная FreeBSD. Да-да. 2019 год, 200Gbp/s. Где там правящая балом нетбзд и wasabi systems? > Если решили сменить тему и в ссылки поиграть. Ну вот рандомная ссылка > в стиле "у меня всё равно больше". > http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever > Просто надо смириться - NetBSD технологический флагман, и из нетки годами все Сам задал тему >> Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти >> ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems... сам слился, сам обвинил в смене темы. Красота! > ps а вообще конечно обидно за фряху... раньше была популярной системой, а > сейчас зайдёшь в темы про фряху и видишь этот вечный пример > про нетфликс или zfs... убогая __нищета__ аргументов, как говорится... Зато надежно конфузит смузихлебов и перепончатых любителей "тперь уже точно совсем как в венде, только нахаляву!" - возразить им нечего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

115. Сообщение от Аноним (-), 29-Июл-20, 00:02	+/–
> Баш на баш. Кстати, да >> Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M. Levy, "Scheduler activations: effective kernel support for    the user-level management of parallelism", ACM Press, ACM Transactions on Computer      Systems, Issue 1, Volume 10, pp. 53-79, February 1992. > The work is based on the scheduler activations kernel interface proposed by > Anderson et al. [1] for user-level control of parallelism in the > presence of multiprogramming and multiprocessing. > [1] Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry > M. Levy. > Scheduler activations: Effective kernel support for the user-level management of parallelism.   > In Proc. 19th ACM Symposium on Operating System Principles, pages 95-109, 1991. > __1991__, Карл. Кроме циферок - неплохо бы и названия и авторов прочитать. > С годами обделались, Почти все верно, только не с годами, а с авторами и статьей. Ну и, судя по всему, не я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

116. Сообщение от Аноним (116), 29-Июл-20, 00:57	+1 +/–
У тебя глюки? Тут никто такого не писал =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

117. Сообщение от Аноним (116), 29-Июл-20, 00:59	+1 +/–
У меня такой дома стоит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #119

118. Сообщение от акуленок я туруруру (?), 29-Июл-20, 01:50	+/–
Фиберы юзали, когда их ав-движки еще толком не разбирали. А инжекты в (приостановленные) потоки уже позже появились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #132

119. Сообщение от Аноним (119), 29-Июл-20, 02:34	+/–
И у меня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

120. Сообщение от Аноним (120), 29-Июл-20, 06:38	+/–
>В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е. Забываем реализацию M:N со стороны IBM для Linux?.. а еще история...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

121. Сообщение от Аноним (121), 29-Июл-20, 09:01	–1 +/–
> Просто надо смириться - NetBSD технологический флагман, и из нетки годами все > кому ни лень рипали идеи (линукс, фряха, опёнок и тп). Идеи в IT видите ли рипают все друг у друга понемногу. Тот же clone() в Linux значительно более мощный сискол нежели просто реализация fork и execve и позволяет намного больше. И это вроде аж частично с plan9 было слизано. А чтобы называться флагманом... а какие там собственно технологии в юзабельном виде есть? Ну хоть файловая система, чтоли, какая лучше чем у других? Или какие-то еще уберполезные по жизни фичи, которых у других нет? Ну там виртуализатор, круче только яйца? Система контейнеров, стройная и изначально заложенная в дизайн ядра? Или, ...,  чего? > NetBSD тестовый, академический полигон. Тут нет ничего необычного... Взаимоисключающие параграфы. Это противоречит заявлениям про флагманов. Извините, большая часть лабораторных установок разбирается и списывается в утиль. И лишь очень небольшой процент доводится до ума, и выглядит в пригодном к применению виде несколько иначе нежели на столе в лабе. > Про крутые программисты там сидят и пишут для души... И даже совсем не на гранты вон тех проприетарщиков? :) > А этот ваш продакшн утаскивает идейки из нетки, обкатывает их... А знаете, компьютер пригодный для продакшна - штука все-таки хорошая. Потому что в конечном итоге для дущи - это прекрасно. А еще прекраснее если всем этим потом еще и пользоваться для решения практических задач можно, а не только как экспонат на музейную полочку - мол, концепт крутой, но чего-то не взлетел. А то круто получается, рассказывать про душу, под дуалбут в пробэкдореную блобосистему то. > про нетфликс или zfs... убогая __нищета__ аргументов, как говорится... "Хода нет - ходи с бубей".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

123. Сообщение от Аноним (-), 29-Июл-20, 09:04	+1 +/–
> Даже окружающую среду не портят, в отличие от гномеров :) Как это? Они производят углекислый газ и даже метан. Это парниковые газы!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

124. Сообщение от Аноним (-), 29-Июл-20, 09:07	+1 +/–
> Во бомбит, а. Пока что по очкам либеральные негромакаки уделывают. Иди, попробуй > им скажи в лицо что важны все жизни. Иди вон в команду Шигорина линух на брусы пилить, там тебе покажут всю мощь и крутизну подходов, чтоли. Сможешь проникнуться всей прелестью из первых рук, так сказать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #140

125. Сообщение от Аноним (125), 29-Июл-20, 09:31	+2 +/–
Тут нужны оговорки. Первое это различать три вещи: 1. Корутины 2. Протопотоки 3. Фиберы То, что ты показал не юзабельно, т.к. не используется одна важная инструкция современных процессоров -- JMP (b для ARM). Тут пример без jmp, но это, имхо, также из серии сделал-по-приколу, но более юзабельно чем то, что ты показал: https://github.com/spc476/C-Coroutines >А async/await как по мне - вреден, ибо большинство смузипрогеров даже не вникает в то, как это работает. >Реально есть кадры, которые на полном серьёзе считают, что корутины - это про мультитрединг. Если речь про async/await из C#, то там действительно они работают в режиме многопоточности. Это происходит просто потому, что операция await применяется к конкретному потоку (который заранее создан встроенным планировщиком) и не избирается автоматически для main-потока. И вообще, в C# нет корутин в юзерспейсе, равно как и файберов, хотя были реализации на сишных/плюсовых либах. В других ЯП, корутины, основанные на jmp, можно оборачивать в конкретный поток, чтобы избавиться от ожидания операций с блокирующими доступом. В частности, контейнером для корутин могут быть форкнутые процессы. Вывод, если ты смеешься над другими и точно знаешь нижележащую реализацию, то ты молодец. А если ты не знал сказанного выше, тогда мы посмеемся над тобой )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

126. Сообщение от Ordu (ok), 29-Июл-20, 10:06	+/–
Реальные многопоточные приложения очень разные. Нет какой-то одной модели, которая позволит оценить влияние и будет верна для всех. Тебе предлагается думать своей головой: подумать о том, как работает твоё приложение, насколько часто оно переключает контексты, и как оно может выиграть от снижения стоимости переключения на порядок. Вообще, лучше даже не думать, а взять и померять частоту переключений контекстов в своём приложении и посчитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

127. Сообщение от Аноним (127), 29-Июл-20, 10:27	+/–
> Просто надо смириться - NetBSD технологический флагман Да уже все смирились, не волнуйся! Вон NetBSD - на большинстве северов, заняла топ-500 и к доминированию на десктопах подбирается. Всё-таки не зря там профессионалы пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

128. Сообщение от Аноним (111), 29-Июл-20, 10:33	+/–
Увы, уже давным-давно не технический флагман и сама тащит в себя с линукса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

130. Сообщение от Аноним (111), 29-Июл-20, 10:36	+/–
>гугел что-то там открывает Исходный код открывает. Заголовок переведённой статьи провокационный и не отражает суть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

131. Сообщение от Аноним (131), 29-Июл-20, 12:50	+/–
>>минусомет >>аргументов к #60 так и не последовало, только вопли оправдывания и смузихабрабные минусики. > Много чести. А, ну да - не царско-анонимное это дело, аргýменты приводить. > Таблеточки всё же пропейте. Я автор тех комментариев и поставил > не более одного раза минус и у меня СОВСЕМ НЕ ПРИГОРЕЛО, СЛЫШЫШ!! > Бла-бла. Т.е. по теме компетентности разрабов и проч - не будет ничего. Яснопонятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

132. Сообщение от n00by (ok), 29-Июл-20, 14:23	+/–
Давайте внесём ясность. Машинный код располагается в ячейках памяти, а те - в адресном пространстве (АП). АП принадлежит объекту "процесс". Сам процесс в NT не исполняется, исполняются его потоки. Зловред копирует свою "полезную" нагрузку в АП браузера и создаёт там новый поток (каким образом -- дело десятое). Это и называется инъекция кода (инжект), соответственно -- в процесс. Это задача "что бы работало". Если перекрыть вектор атаки, отвалится масса г-на. А если фиберы применяли для надурить эвристику -- по-моему, эта задача называется "генерация исполняемого мусора"? Если запретить фиберы, зловреды особо не пострадают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #136

133. Сообщение от n00by (ok), 29-Июл-20, 14:31	+/–
Ответ прост как 2 копейки: сделайте доброе дело, прекратите шарлатанство и профанацию с этой вашей Розалинукс, пока люди не пострадали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #145

134. Сообщение от Аноним (134), 29-Июл-20, 17:28	+/–
Статические переменные внутри функции? Не велели такого отцы-основатели
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

136. Сообщение от акуленок я туруру (?), 29-Июл-20, 18:26	+/–
Да, опечатался, в приостановленный процесс, но для локальной эскалации. CreateRemoteThread вроде, потом это дело быстро прикрыли конечно. Ничего не мешало навесить на фиберы полезную нагрузку, просто движки их не парсили. Мусор тут нипричем. Это вроде как с файловыми потоками в NTFS было. Security through obscurity.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #137

137. Сообщение от n00by (ok), 29-Июл-20, 19:21	+/–
> Да, опечатался, в приостановленный процесс, но для локальной эскалации. CreateRemoteThread > вроде, потом это дело быстро прикрыли конечно. Там были ещё варианты. Вот что пишет специалист, первым разобравший Rustock.C: "имеет в составе библиотеку, внедряемую в один из системных процессов ОС Windows." https://www.drweb.ru/upload/56d8247826582537818c3a7de8949928... т.е. явно без CreateRemoteThread, поскольку делал это из ядра. > Ничего не мешало навесить на фиберы полезную нагрузку, То есть пропатчить код приложения-жертвы для вызова SwitchToFiber()? В таком случае возможно и непосредственно "нагрузку" врезать. Сама SwitchToFiber(), насколько помню, кроссплатформенно сохраняет регистры и ничего особенного не делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

138. Сообщение от Аноним (138), 29-Июл-20, 20:41	+/–
Планировщик должен быть на основе нейросети.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #158

139. Сообщение от Аноним (139), 29-Июл-20, 21:09	+1 +/–
Can anything good come out of google?
Ответить | Правка | Наверх | Cообщить модератору

140. Сообщение от Тот_Самый_Анонимус (?), 29-Июл-20, 22:24	–1 +/–
Бла-бла-бла. Пока ты языком мелешь, очередной ниггер убивает очередного белого. Езжай туда скорее. этим белым можешь быть ты. Докажи делом свои слова, тряпка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #144

141. Сообщение от Аноним (141), 29-Июл-20, 23:12	+/–
Ну как же не производят... Они дурно влияют на неокрепшие умы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

142. Сообщение от Consta (?), 30-Июл-20, 00:33	+1 +/–
Какая то странная реакция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #148, #157

143. Сообщение от deAdm (?), 30-Июл-20, 02:39	+/–
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск? > 24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да > еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей > ARI-стазисов и еще и внутренних AGI-подпрограмм. очень доходчиво.спс а с фрисвич практика параллели?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

144. Сообщение от Аноним (144), 30-Июл-20, 07:08	+/–
> Бла-бла-бла. Пока ты языком мелешь, очередной ниггер убивает очередного белого. Езжай туда скорее. Эм, ну вообще я в европы как-то перебираюсь. Потому что наслаждаться росиянскими гестапцами до гроба мне западло. Но вообще, если представится удобная оказия - я и к линчевателям негров согласен. > этим белым можешь быть ты. А я вот и отличные от твоей тупой пропаганды варианты видел - например фоточки, где негры и белые одной стеной, за одни слоганы. И я даже нахожу что слоган "black lives matter" меня вполне устраивает. Более того, собственно, после известных действий полиции я этих граждан вполне понимаю в их недовольстве такими действиями представителей государства. Только россияне могут дохнуть миллионами и не возмущаться. А вот даже негры не настолько глупые по жизни и вот так делать все же не собираются. А за такую феерическую тупизну, видите ли, отливается. На уровне демографии и национального состава уже попросту. Это конечно можно игнорировать, но когда в 6 утра тупо ни 1 русского слова на улице... на мой вкус это уже давно превысило все мыслимые рамки. Особенно умильно когда про это вот вещают в контексте европ, но ни звука про то что крупные города стали каким-то Ташкентом у себя. Вот европейцы в этом как-то честнее и рациональнее, они в зеркало иногда смотрятся, вместо перевода стрелок. > Докажи делом свои слова, тряпка. Когда я что-то говорю, это обычно худо-бедно обеспечено технически "в фоне". Так что насчет тряпок мы будем посмотреть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

145. Сообщение от Аноним (144), 30-Июл-20, 07:13	+/–
> Ответ прост как 2 копейки: сделайте доброе дело, прекратите шарлатанство и профанацию > с этой вашей Розалинукс, пока люди не пострадали. Смотрите, дети: классический пример нездоровой фиксации и фобий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #147

146. Сообщение от Аноним (60), 30-Июл-20, 07:18	+/–
> Вопрос имею: а вот вынос планировщика в юзерспейс - как оно концептуально > с точки зрения безопасности? Какие будут мнения? ИМХО - "никак". Это для удобства приложений с кооперативными корутинами или типа того. На работу ядра это не особо влияет, кроме того что некоторые операции - сильно дешевле. А секурити модель или способность ядра выпереть тред с проца это не отменяет. Просто в пределах того треда может еще быть некая кооративная дележка, которая НЕ ТРЕБУЕТ ЩЕЛКАТЬ ПОЛНЫМ КОНТЕКСТОМ, телепаться между юзером и кернелом и проч. А ядро что, ему в принципе не обязательно знать как там внутри себя программа работает, оно энфорсит общие лимиты ресурсов и делает окончательный арбитраж. Тонкости того как именно прога теми ресурсами воспользуется в пределах лимитов - а какое ядру до этого дело? Реально там основные сложности с другими вещами - там в работе были еще некие патчи затрагивающие смежные вещи и вот там есть определенные грабли. Но об этом есть в рассылке. Читайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #150

147. Сообщение от n00by (ok), 30-Июл-20, 07:39	+/–
Это ты тот персонаж, которого ссылка на Пуфлера https://sun9-20.userapi.com/b8qwsxYAWkpKCMqlux_9f-uH0PVRsj1J... из Розалинукс бомбанула и вынудила отвечать на все подряд мои комментарии? Ничего личного к этим проходимцам в няшных чепчиках, но инфраструктура там слегка, эмм... скомпрометирована https://vk.com/video-33847957_456239489 Такую систему в просторечии называют "дырявой". Совпадение? Не думаю! (с)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

148. Сообщение от n00by (ok), 30-Июл-20, 07:43	–2 +/–
Не знать что-либо -- само по себе не плохо. Но когда неуч начинает продавать свою безграмотность, это не только аморально, но и опасно. Хорошо еще, если твой сайт ООО "НТЦ ИТ РОСА" https://vk.com/video-33847957_456239489 тупо ломанули ботом и за 2 дня до того, как вы узнали об этом из ВК, а не полгода назад, протроянив всех пользователей, включая гос.учреждения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #149

149. Сообщение от Consta (?), 30-Июл-20, 10:08	–1 +/–
Ты какой то странный. К доктору ходить не пробовал? У меня нет никаких сайтов. Доброе утро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #154

150. Сообщение от Consta (?), 30-Июл-20, 10:19	+/–
Спасибо. Но я бы смотрел чуть по другому. Раз это юзерспейс процесс, то он, по идее, подпадает под лимитирование. И что там будет в случае перегрузки - предсказать сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

151. Сообщение от Яков (?), 30-Июл-20, 11:31	+/–
Ну, вместо TLS можно использовать FLS, ино дело, что сразу теряешь языковую поддержку - __declspec(thread) и thread_local сразу становятся не про нас, ну и библиотечные вызовы, где TLS используются (иногда неявно - см. errno) идут лесом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

152. Сообщение от Аноним (152), 30-Июл-20, 12:45	+/–
>Интересно кто первый угробит линукс - гугл или микрософт? Поттеринг и гномеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

153. Сообщение от Аноним (152), 30-Июл-20, 12:55	+/–
На JavaScript!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

154. Сообщение от n00by (ok), 30-Июл-20, 18:28	+/–
Расскажи еще, что никогда в той шаражке не работал, не собеседовал и не трудоустраивал туда бестолочей (кого ты ещё можешь принять с "вопросами" из #82?), не учил г-на Потапова грамотно попрошайничать, создавая так называемое НКО (результаты деятельности которого вы изначально намеревались монетизировать) РОСПО. Напиши, что ты некий левый чел, который пишет с того же ника наивные откорячки с характерной стилистикой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

156. Сообщение от Аноньимъ (?), 01-Авг-20, 10:56	+/–
Да какая разница если они всё забросили и все полимеры пр*с**ли? В бсде вообще ленивые смешные люди сидят которым на ОС и технологии плевать, у них свои какие-то абскурные задачи, на половину академические (пример Беркли) наполовину чисто коммерческие (фаерволы гонять)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

157. Сообщение от Ordu (ok), 02-Авг-20, 01:18	+1 +/–
Да потому, что вопрос твой -- бред. Представь себе программу. Программа выполняет много операций, некоторые дольше, некоторые быстрее, некоторые блокируются в ожидании какого-то внешнего события. Классически эти операции упорядочивались программистом и выполнялись последовательно. Потом набор операций для выполнения стали разбивать на несколько потоков, каждый из которых был упорядоченным потоком операций. И упорядочивал опять же программист. Но тогда же пилили "зелёные" треды: они позволяют программисту упорядочивать операции во много потоков, и потом в рантайме эти потоки будут перетасовываться в один поток -- это удобно тем, что программист может писать код работы с http-соединением как последовательный, но когда этот код заблокируется в ожидании свежих данных из сети, ядерный поток выполнения не заблокируется, потому как в юзерспейсе будет выполнено переключение "зелёных" тредов, и продолжит выполнятся поток, который не заблокирован. В принципе, всё это было просто другим способом делать select/epoll: select/epoll прятались в библиотеке зелёных потоков, а программист писал, будто бы у него на каждое соединение свой собственный ядерный тред. Но сочетать ядерные потоки с юзерспейсными сложно. Все попытки делать это в C разбивались об эту сложность. Тем временем функциональные языки потихоньку осваивали это дело. Гугл понаблюдал за ними, и запилил корутины в Go. Фишка в том, что программист комбинирует операции, задавая порядок выполнения, а потом рантайм эти операции раскидывает по ядерным потокам, выполняя что-то параллельно, а что-то последовательно. Это очень упрощённая версия истории событий, но основной вывод отсюда: корутины и юзерспейс-многозадачность -- это разные способы для программиста выполнять те же самые задачи мультиплексирования ввода/вывода, то есть переупорядочивать операции, выполнять их по мере готовности данных, по возможности выполнять максимум операций параллельно на разных ядрах, и тп. Повышение или снижение безопасности может случится, если один из подходов больше способствует возникновению программерских ошибок, а другой меньше. Но... ты действительно хочешь об этом поговорить? Что-то мне подсказывает, что это не то, что тебя интересует. И поэтому я говорю тебе: вопрос твой -- бред. И поэтому ты получаешь минусы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

158. Сообщение от ыыы (?), 02-Авг-20, 18:20	+/–
и блокчейна
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #159

159. Сообщение от Аноним (159), 04-Авг-20, 22:14	+/–
обязательно с шифрованной арифметикой ключом 65536 бит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

160. Сообщение от rshadow (ok), 12-Авг-20, 13:53	+/–
https://ru.wikipedia.org/wiki/%D0%A1%D0%...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема