Я приценился - решение отличное, но правда не из дешевых. А нет ли попроще решения, которое может быть не обладает функциями управления, а лишь только делает захват картинки? Причем не обязательно через интернет.
О - похоже, что то, что нужно! Спасибо большое за разъяснение. А с точки зрения забора изображения - оно представляется монитором? И еще вопрос - для того, чтобы наблюдать на втором компьютере за работой первого - нужно установить специальный софт?
Ух, навороченная картинка)) Как я понял - такая штука заточена именно под управление через интернет и потребует установки софта на захватываемой машине, что мне не подходит. Или ею можно подключиться напрямую без установки этого самого софта?
Про KVM я тоже читал некоторое время, но опять же, принцип работы с ними все описывают, как будто читающие уже имеют эту KVM на руках и знают на 50% что к чему. Но ни одного гайда объясняющего "с нуля" все тонкости я не нашел. Важный для меня момент - как KVM выглядит для захватываемой машины - как монитор мышка и клавиатура? Или как специальное устройство, которое может вызвать подозрения?
Вы имеете ввиду, что блокировка где-то внутри библиотеки awesomium происходит? Просто с моей стороны тут вроде даже возможности нет нигде ее поставить.
Если у вас будет минутка - напишите мне пожалуйста. Все же быстрее и проще разобраться, когда можно онлайн общаться. Заранее спасибо большое.
Я кажется понял вашу идею. Вы хотите сказать, что сам Action, который я передаю в Task.Run выполняется синхронно и тем самым блокирует выход из самого таска и соответственно блокирует освобождение потока, который его выполняет. Но этот же Action, который является лямбда выражением - по сути асинхронный метод и по всем правилам должен вернуть управление, при первом же встреченном await. А когда он возвращает управление, то и таск завершается и поток освобождается. Если я понимаю не правильно, то тогда все встает на свои места, но я не нашел пока в инете ничего противоречащего моим суждениям. В некоторых блогах даже советуют использовать Task.Run(async ()=> { await ... });
Спасибо большое за ответ. Я уже почти начинаю понимать, но еще остаются непрозрачные моменты.
Помогите разобраться, пожалуйста, с последним вопросом - почему мы не выйдем из лямбды (а соответственно из метода и задачи) на первом же await? Я предполагал, что да, все задачи дружно пойдут в очередь и начнут выполняться последовательно (относительно количества потоков), НО, как только в каждой задаче мы дойдем до первого await, мы сразу из нее выйдем и дадим дорогу другой в очереди. Таким образом, мне казалось, что уж запуститься все задачи должны почти моментально и также почти моментально дойти до асинхронной части (I/O операции) и после этого уже параллельно ждать завершения I/O операций. Неужели все таки будет все не так?
Спасибо еще раз. Может быть вам было бы удобнее в скайпе общаться? Если что, мой скайп: babushkamoroz
Моя идея в том, что тот код, что я написал, вообще не должен требовать процессорного времени. То есть там все почти моментально, а I/O операции идут асинхронно и не занимают поток.
Не до конца понял, почему await скорее всего превратит вызов последнего метода в синхронный. Даже если так, то этот метод (а точнее таск, который его содержит) вызовется только тогда, когда отработает асинхронная I/O операция запроса. Да и сам метод этот, как я писал, очень быстрый (по сути я и без обработки данных проверял - та же проблема).
Я согласен, что запускать на каждый запрос новый поток глупо, но я не поток запускаю, а создаю таск, который уже сам там решит, в каком потоке ему выполняться. Это довольно дешевая операция (не сравнима с созданием потока). Думаете, все-таки тут затык?
Вот я хожу вокруг этого "старого механизма" и не могу понять, чем он лучше моего варианта? Поможете разобраться?
Начнем с того - чем плох Task.Run и async/await? Как я понимаю, мы да, сначала делаем тучу тасков и они попадают в тредпул, но на моменте первого await у каждого из тасков создается туча колбеков, остальная часть методов оборачивается в другую тучу тасков, начинается туча асинхронных запросов, которые не блочат поток и потом, по завершению каждого запроса, дергается колбек и выполняется завершающий кусок метода в виде отдельного таска. В моем понимании нигде не происходит блокировки и не вижу узкого места. Единственное, что я забыл указать в своем семле - что я использую .ConfigureAwait(false), что добавляет еще больше свободы в выборе потока, где выполняться будет завершающий кусок метода.
Подскажите, пожалуйста, где я не прав? Чувствую, что наломал дров, но в упор не вижу где..
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.