Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Тогда этот фоновый поток будет у меня не таким тупым, а станет например актором. С которым gui-поток (тоже есть естественно актор) будет общаться с помощью сообщений. Ну или вместо акторов можно CSP взять — это уже зависит от остальных частей приложения. ) НС>А можно взять модель фьючерсов, которая тоже имеет право на жизнь.
Согласен.
И кстати сразу замечу, что к сопрограммам (как к инструменту "выпрямления") у меня никогда не было никаких претензий ни в каких языках. Да, имеют место различные споры по реализации (стековые, бесстековые и т.п.), но сама концепция — это однозначно полезный сахар. Все мои претензии в этой области относятся исключительно к сомнительному применению асинхронного ввода-вывода где-либо за пределами той узкой области, где он реально полезен. Ну а без асинхронного ввода-вывода "выпрямлять" то обычно и нечего...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Future или promise. Но МС любит альтернативную терминологию вводить. НС>А сontinuation это ортогональное понятие, это не про таски, а про async/await.
С чего это оно не про таски? Task.ContinueWith прекрасно существует без async/await'ов. Это async/await'у без него туго было бы.
Здравствуйте, alex_public, Вы писали:
_>Ничего себе. И что, все они стартуют сразу при старте любого .net приложения? Или надо начать асинхронный ввод-вывод? Или всё же не все сразу?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Потому что для асинхронности может быть достаточно одной таски(=поток). НС>Ничего не понял. Что значит достаточно одной таски и почему это важно? И нет, таска != поток.
Асинхронность не тождественна понятию "task". Одной таски, которая в данном частном случае будет 1:1 с потоком,
хватит для асинхронности.
S>> Библиотека для работы и создания таксков тут может быть излишняя. НС>Для чего излишняя?
Она вообще не нужна, если цель асинхронность. См. non-blocking io, select/epoll и т.д.
S>>Очень классно сформулировано . Единственное что не нравится, это слово callback, уж больно оно перегружено. НС>В данном контексте оно имеет вполне конкретное значение.
Т.к. ниже замечено, что callback -- это принцип. А тут речь идет об абстракциях, которые могут быть самостоятельно запланированы,
так и организованы в структуру даннах -- т.е. одно после другого, одно после всех и т.д.
S>>Т.е. слово future или сontinuation подошло бы больше. НС>Future или promise. Но МС любит альтернативную терминологию вводить. НС>А сontinuation это ортогональное понятие, это не про таски, а про async/await.
сontinuation именно про таски, я называю так код в ContinueWith(t=>{some code},options). Собственно,
продолжением можно считать код после выражения await(это не совсем так, там другой принцип -- КА, но суть в том,
чтобы выполнить задачу,после этой задачи). А async\await -- сахар для организации задач(и) в структуру данных.
Здравствуйте, Kolesiki, Вы писали:
K>Что такое вообще слово "асинхронно"?
"Not synchronous; occurring at different times." https://en.wiktionary.org/wiki/asynchronous
K>Это значит, что есть минимум 2 неких процесса, работающих независимо друг от друга (т.е. им не надо синхронизировать друг с другом свою работу). Так что любой трэд, TPL или нечто "сбоку" от главной программы — это и есть "асинхронное исполнение".
Асинхронность никаких процессов, тредов, задач не подразумевает вообще, от слова совсем.
Достаточно одного любого исполнителя. Эти абстракции вводят для того, чтобы эффективнее
утилизировать CPU, повышать отклик системы и т.д. Почитайте как с nodejs и
подобные сервера с помощью одного потока и non-blocking io держат не хилую нагрузку.
S>>Результат io операции в асинхронном случае получает iocp поток, зачем ему ждать пользовательский поток? Т.е. S>>callback (это же можно назвать сопрограммой?) будет выполнен в контексте iocp потока.
_>Я тут имел в виду, что если ты напишешь что-то вроде: _>
_>data=await DownloadFile();
_>Parse(data);
_>
_>в gui потоке, то функция parse опять же будет вызвана в gui потоке, который на момент отработки соответствующего Iocp потока вполне может быть чем-то занят.
Отличный пример! Не будет он ничего ждать, потому что именно для этого существует контекст
синхронизации(synchronizationcontext). iocp поток сделает post соотв. контексту и будет свободен.
За одно еще больше понял роль всяческих synchronizationcontext'ов.
Здравствуйте, Sharov, Вы писали:
S>Асинхронность не тождественна понятию "task".
А кто то утверждал что тождественна?
S> Одной таски, которая в данном частном случае будет 1:1 с потоком, S>хватит для асинхронности.
И?
S>>> Библиотека для работы и создания таксков тут может быть излишняя. НС>>Для чего излишняя? S>Она вообще не нужна, если цель асинхронность.
Ничего не понял.
S> См. non-blocking io, select/epoll и т.д.
И?
S>>>Т.е. слово future или сontinuation подошло бы больше. НС>>Future или promise. Но МС любит альтернативную терминологию вводить. НС>>А сontinuation это ортогональное понятие, это не про таски, а про async/await. S>сontinuation именно про таски,
Нет.
S>чтобы выполнить задачу,после этой задачи). А async\await -- сахар для организации задач(и) в структуру данных.
Здравствуйте, Lexey, Вы писали:
НС>>Future или promise. Но МС любит альтернативную терминологию вводить. НС>>А сontinuation это ортогональное понятие, это не про таски, а про async/await. L>С чего это оно не про таски? Task.ContinueWith прекрасно существует без async/await'ов. Это async/await'у без него туго было бы.
Continuation, конечно, про таски. Но вот async\await обходится без них -- там КА строится.
Здравствуйте, Sharov, Вы писали:
S>>> Одной таски, которая в данном частном случае будет 1:1 с потоком, S>>>хватит для асинхронности. НС>>И? S>TPL для асинхронности не нужна.
А кто говорил что обязательно нужна?
S>>> См. non-blocking io, select/epoll и т.д. НС>>И? S>Что и?
К чему ты это написал?
S>>>сontinuation именно про таски, НС>>Нет. S>Почему нет?
Потому что continuation может быть без тасков и таски без continuation.
Здравствуйте, Kolesiki, Вы писали:
K>Зачем нам нужна асинхронность? (в контексте GUI программ, взаимодействующих с юзером) K>... K>Заметьте — я ничего не говорю про мультипоточность — она нужна, хотя опять же, далеко не везде. K>...
А вот я считаю, что многопоточность не нужна. По крайней мере не нужна в том виде, в каком она сделана сейчас почти везде. Нельзя свободно давать писать разным потокам в одну облась памяти, а затем долго трахаться с выявлением всех дед локов и рэйс кондишенов, и в итоге получить решение, работающее в разы медленнее чем однопоточное.
Для параллельного исполнения вполне можно и нужно использовать несколько процессов а не потоков. Для того, чтоб организовать работу нескольких задач в рамках одного процесса можно и нужно использовать ассинхронность. А от тредов одни проблемы! Впринципе так оно и работало когда-то, не знаю, почему в свое время начали активно везде внедрять эти потоки, причем их активно пропагандировали еще до массового появления многоядерных процессоров.
Здравствуйте, ksandro, Вы писали:
K>Здравствуйте, Kolesiki, Вы писали:
K>>Зачем нам нужна асинхронность? (в контексте GUI программ, взаимодействующих с юзером) K>>... K>>Заметьте — я ничего не говорю про мультипоточность — она нужна, хотя опять же, далеко не везде. K>>...
K>А вот я считаю, что многопоточность не нужна. По крайней мере не нужна в том виде, в каком она сделана сейчас почти везде. Нельзя свободно давать писать разным потокам в одну облась памяти, а затем долго трахаться с выявлением всех дед локов и рэйс кондишенов, и в итоге получить решение, работающее в разы медленнее чем однопоточное.
Ну а что вместо потоков? Ну можно например держать поток(и) только для записи и организовать очередь. Можно сделать версионность как в БД для чтения.
K>Для параллельного исполнения вполне можно и нужно использовать несколько процессов а не потоков. Для того, чтоб организовать работу нескольких задач в рамках одного процесса можно и нужно использовать ассинхронность. А от тредов одни проблемы! Впринципе так оно и работало когда-то, не знаю, почему в свое время начали активно везде внедрять эти потоки, причем их активно пропагандировали еще до массового появления многоядерных процессоров.
Ну вот берем БД и как несколько процессов решит проблему проблему с чтением записью в файл.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sharov, Вы писали:
НС>>А кто говорил что обязательно нужна? S>
S>2) В дотнете есть такая штука как TPL. Вот это уже та самая асинхронность.
S>TPL для асинхронности не нужна.
В цитате нет слов "обязательно" и "нужна".
S>>>>> См. non-blocking io, select/epoll и т.д. НС>>>>И? S>>>Что и? НС>>К чему ты это написал? S>Про механизмы, обеспечивающие асинхронность с одним потоком.
И?
S>>>Почему нет? НС>>Потому что continuation может быть без тасков и таски без continuation. S>continuation это таска-продолжение другой таски, как она может быть без?
Может быть ровно одна таска. Может быть Parallel.For. И т.п.
S> Хотелось бы пример: S>
Здравствуйте, Serginio1, Вы писали:
S>>Continuation, конечно, про таски. Но вот async\await обходится без них -- там КА строится. S>Ну вот вызов Next КА вполне себе может выполнять ContinueWith
Но не выполняет.
И, в любом случае, это внутренние детали реализации асинков, на общую схему это не влияет никак. Завтра поменяют КА на вызов ContinueWith и ничего принципиально при этом не поменяется.
Здравствуйте, ksandro, Вы писали:
K>не знаю, почему в свое время начали активно везде внедрять эти потоки, причем их активно пропагандировали еще до массового появления многоядерных процессоров.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>>>Continuation, конечно, про таски. Но вот async\await обходится без них -- там КА строится. S>>Ну вот вызов Next КА вполне себе может выполнять ContinueWith
НС>Но не выполняет.
НС>И, в любом случае, это внутренние детали реализации асинков, на общую схему это не влияет никак. Завтра поменяют КА на вызов ContinueWith и ничего принципиально при этом не поменяется.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, ksandro, Вы писали:
K>>не знаю, почему в свое время начали активно везде внедрять эти потоки, причем их активно пропагандировали еще до массового появления многоядерных процессоров.
НС>Ну так узнай.
Ну, расскажи! Какие вообще плюсы у потоков перед процессами? Как по мне так в текущих реализзациях многопоточность дает только возможность понаделать кучу ошибок на ровном месте, иольше ничего!
. Единственное что не нравится, это слово callback, уж больно оно перегружено.
