Здравствуйте, Mazay, Вы писали:

M>Заметьте, этот код писался летом-осенью 2011 года, когда в C# ещё не было await.

В те времена была библиотека power threading, открой её и посмотри, насколько все просто.

Здравствуйте, alex_public, Вы писали:

_>Хорошо бы на примере nginx... Он как раз с относительно небольшими исходниками, а при этом занимает второе место после апача среди активных сайтов и применяется обычно на самых нагруженных...

Кстати, еще один хороший аргумент — nginx целиком и полностью на С. Казалось бы, раз С++ такой крутой, почему такой хардкор пишут на С ?

Здравствуйте, alex_public, Вы писали:


_>

_>void Window::Handler(object& sender, TaskArgs& args)
_>{
_>    thread([&](){
_>        HttpClient client;
_>        auto response=client.GetSync(args.Url, args.Cancellation);
_>        response.EnsureSuccessStatusCode();
_>        PostMessage(NEW_DATA, response.Content.ReadAsStringSync());//PostMessage - функция-член Window
_>    }).detach();
_>}
_>void Window::OnNewData(const Data& data)
_>{
_>    textBox.Text+=data.get<string>();
_>}
_>

_>Оно конечно чуть более многословно... Но зато и намного проще и расширяемо. Ну и кстати эффективнее с точки зрения производительности, хотя в таких задачах это обычно не важно.

Не совсем понятно, где то расширяемость, если для каждого случая надо писать какой то уникальный код

Здравствуйте, Ikemefula, Вы писали:

M>>Заметьте, этот код писался летом-осенью 2011 года, когда в C# ещё не было await.

I>В те времена была библиотека power threading, открой её и посмотри, насколько все просто.

Ну посмотрел. Увидел пул потоков. Покажи как там просто организовать асинхронную работу в одном потоке.
https://github.com/Wintellect/PowerThreading/blob/master/PowerThreading-Desktop/Wintellect.Threading/ReaderWriterGate/ReaderWriterGate.cs

 /// <summary>Initiates an asynchronous write operation.</summary>
      /// <param name="callback">The method that will perform the write operation.</param>
      /// <param name="state">A value passed to the callback method.</param>
      /// <param name="asyncCallback">An optional asynchronous callback, to be called when the operation completes.</param>
      /// <param name="asyncState">A user-provided object that distinguishes this particular asynchronous operation request from other requests.</param>
      /// <returns>A System.IAsyncResult that represents the asynchronous operation, which could still be pending.</returns>
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Reliability", "CA2000:Dispose objects before losing scope")]
      public IAsyncResult BeginWrite(ReaderWriterGateCallback callback, Object state,
        AsyncCallback asyncCallback, Object asyncState) {
         AsyncResult<Object> ar = new AsyncResult<Object>(asyncCallback, asyncState);
         ReaderWriterGateReleaser releaser = new ReaderWriterGateReleaser(callback, this, false, state, ar);
         m_syncLock.Enter(true);
         switch (m_state) {
            case ReaderWriterGateStates.Free: // If Free "RFW -> OBW, invoke, return
            case ReaderWriterGateStates.ReservedForWriter:
               m_state = ReaderWriterGateStates.OwnedByWriter;
               ThreadPool.QueueUserWorkItem(releaser.Invoke);
               break;

            case ReaderWriterGateStates.OwnedByReaders: // If OBR | OBRAWP -> OBRAWP, queue, return
            case ReaderWriterGateStates.OwnedByReadersAndWriterPending:
               m_state = ReaderWriterGateStates.OwnedByReadersAndWriterPending;
               m_qWriteRequests.Enqueue(releaser);
               break;

            case ReaderWriterGateStates.OwnedByWriter: // If OBW, queue, return
               m_qWriteRequests.Enqueue(releaser);
               break;
         }
         m_syncLock.Leave();
         return ar;
      }

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Ikemefula, Вы писали:

M>>>Заметьте, этот код писался летом-осенью 2011 года, когда в C# ещё не было await.

I>>В те времена была библиотека power threading, открой её и посмотри, насколько все просто.

M>Ну посмотрел. Увидел пул потоков. Покажи как там просто организовать асинхронную работу в одном потоке.
M>https://github.com/Wintellect/PowerThreading/blob/master/PowerThreading-Desktop/Wintellect.Threading/ReaderWriterGate/ReaderWriterGate.cs

А при чем здесь ReadWriterGate ?

Здравствуйте, Ikemefula, Вы писали:

M>>>>Заметьте, этот код писался летом-осенью 2011 года, когда в C# ещё не было await.

I>>>В те времена была библиотека power threading, открой её и посмотри, насколько все просто.

M>>Ну посмотрел. Увидел пул потоков. Покажи как там просто организовать асинхронную работу в одном потоке.
M>>https://github.com/Wintellect/PowerThreading/blob/master/PowerThreading-Desktop/Wintellect.Threading/ReaderWriterGate/ReaderWriterGate.cs

I>А при чем здесь ReadWriterGate ?

Мне показалось, что именно он предназначен для асинхронного чтения/записи. Нормальной документации и примеров я за 5 минут не нашёл. Ну, короче, ты же с этой библиотекой лучше знаком — покажи примеры, код.

Здравствуйте, Cyberax, Вы писали:

C>На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи).

Один вон тоже в дебиане openssl валгриндил... Знаешь что с ним стало?

Здравствуйте, Константин Б., Вы писали:

C>>На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи).
КБ>Один вон тоже в дебиане openssl валгриндил... Знаешь что с ним стало?
Пока что ничего. И вообще, 65536 ключей должно быть достаточно для всех!

Это я к тому, что shit happens, но не так уж часто.

Здравствуйте, Mazay, Вы писали:

I>>А при чем здесь ReadWriterGate ?

M>Мне показалось, что именно он предназначен для асинхронного чтения/записи. Нормальной документации и примеров я за 5 минут не нашёл. Ну, короче, ты же с этой библиотекой лучше знаком — покажи примеры, код.

Я на ней пару вещей всего сделал, вместо await был yield и собтвенно всё.

Здравствуйте, Ikemefula, Вы писали:

I>Я на ней пару вещей всего сделал, вместо await был yield и собтвенно всё.

А-а-а. Понятно. yield можно использовать вместо корутин для прерывания и возобновления функций. А дальше всё тоже самое: асинхронный вызов с хэндлером, который вернёт управление в корутину (через обращение к энумератору), и прерывание исполнения функции сразу после этого вызова (yield return).

Здравствуйте, Mazay, Вы писали:

I>>Я на ней пару вещей всего сделал, вместо await был yield и собтвенно всё.

M>А-а-а. Понятно. yield можно использовать вместо корутин для прерывания и возобновления функций. А дальше всё тоже самое: асинхронный вызов с хэндлером, который вернёт управление в корутину (через обращение к энумератору), и прерывание исполнения функции сразу после этого вызова (yield return).

Да, примерно так. Если нужно в одном потоке что бы работало, то по идее для этого нужен шедулер специальный. Не в курсе, правда, есть ли в PowerThreading такой шедулер.

Здравствуйте, Ikemefula, Вы писали:

I>Да, именно так. За подробностями обращайся к сиплюсплюсникам из микрософт

Т.е. подтверждения своим словам не будет? ) Так и запишем, что болтовня просто...

I>Не в курсе что там с nginx

С nginx можно в любой момент глянуть все исходники и они даже не дико объёмные... Так что легко подтвердить или опровергнуть информацию о неком использование ядра... )))

Здравствуйте, Ikemefula, Вы писали:

I>

Что, страшненько? ) Можно подумать что под капотом у .net всё намного красивее. )))

А теперь делаем минимальную украшательную магию:

#define BEGIN_ASYNC coroutines_list.emplace_back([&](Coroutine::caller_type& __coroutines_parameter){
#define END_ASYNC });
#define make_async(e) _make_async<decltype(e)>([](){return e;}, __coroutines_parameter)
template<typename T>
T _make_async(function<T()> l, Coroutine::caller_type& c)
{
    auto r=async(launch::async, l);
    while(r.wait_for(chrono::seconds(0))!=future_status::ready) c();
    return r.get();
}

И тогда тот наш страшненький код можно переписать так:

void handler(object& sender, TaskArgs& args)
{
BEGIN_ASYNC
    HttpClient client;
    auto response=await_async(client.Get(args.Url, args.Cancellation));
    response.EnsureSuccessStatusCode();
    textBox.Text+=await_async(response.Content.ReadAsString());
END_ASYNC
}

Как говорится найдите 10 отличий от C# варианта... Хотя на самом деле 2 отличия есть и оба в пользу C++:
1. Нам не потребовалось заводить в классе HttpClient отдельную функцию для объявления асинхронного вызова — хватило вызова старого синхронного метода. Хотя естественно никто не мешает и отдельно объявить, если реализации различаются.
2. Мы можем здесь добавить код (после END_ASYNC), который выполнится после первого асинхронного вызова, но до его завершения.

Да, но несмотря на все эти красивости я бы всё равно не стал писать так — мне не нравится подобный стиль реализации многопоточности.


I>Красиво, это когда компилятор умеет связывание рахных сортов. В С# тоже можно все упаковать, притом используя именно поддержку компилятора.

Ну так мы и приходим к выводу что данная схема асинхронности одинаково легко реализуется и на C++ и на C#. Только в C# он жёстко зашит, а в C++ мы можем его подстроить под себя как хотим.

Здравствуйте, Ikemefula, Вы писали:

I>Очень интересный вопрос. В вебе вечно не хватает ни перформанса, ни памяти. Очень большой и острый вопрос. Казалось бы — надо всё на С++ писать. Но вот шота прогресс пошел целиком и полностью в менеджед — дотнет, джава, питон, руби, пхп, перл и даже джаваскрипт.

Всё правильно, сейчас в инете большую часть веба занимаeт такой жуткий язык как php. Только вот надо понимать, что это скриптовой язык, который работает просто склейкой различных модулей. А для того что бы оценить на чём реально работает веб, надо посмотреть на чём написан интерпретатор и библиотеки php!

А то с такой логикой может получиться что современные мощные игры написаны на Lua или вообще Oracle Database написана на SQL.

Здравствуйте, Ikemefula, Вы писали:

I>Не совсем понятно, где то расширяемость, если для каждого случая надо писать какой то уникальный код

Чёткое разделение кода и данных разных потоков в разных функциях. При такой схеме не надо продумывать что там куда может маршалиться или не может — всё сразу чётко видно.

Здравствуйте, alex_public, Вы писали:

I>>Да, именно так. За подробностями обращайся к сиплюсплюсникам из микрософт

_>Т.е. подтверждения своим словам не будет? ) Так и запишем, что болтовня просто...

Запусти IIS в юзермоде, да так, что бы всё шоколадно было, приходи и расскажи как я здесь всё наврал.

I>>Не в курсе что там с nginx

_>С nginx можно в любой момент глянуть все исходники и они даже не дико объёмные... Так что легко подтвердить или опровергнуть информацию о неком использование ядра... )))

В винде любая такая софтина может нормально работать только как сервис. nginx на винде пока что ничем не блещет, потому что умеет только синхронные сокеты. И кстати говоря в планах асунуть его в сервис. Интересно, зачем, если и так всё шоколадно ?

Здравствуйте, alex_public, Вы писали:

_>Всё правильно, сейчас в инете большую часть веба занимаeт такой жуткий язык как php. Только вот надо понимать, что это скриптовой язык, который работает просто склейкой различных модулей. А для того что бы оценить на чём реально работает веб, надо посмотреть на чём написан интерпретатор и библиотеки php!

бОльшая часть мелочевки пишется на php, который почему то общепризнанно тормозной. если тормозной скрипт, то странно, почему это живет в вебе, ибо здесь казалось бы место для С++. А если тормозят модули, снова странно — мудули на С++ и тормозят

Здравствуйте, alex_public, Вы писали:

_>Как говорится найдите 10 отличий от C# варианта... Хотя на самом деле 2 отличия есть и оба в пользу C++:
_>1. Нам не потребовалось заводить в классе HttpClient отдельную функцию для объявления асинхронного вызова — хватило вызова старого синхронного метода. Хотя естественно никто не мешает и отдельно объявить, если реализации различаются.

В C# не надо ничего объявлять отдельно. Не совсем ясно, зачем тебе "старый синхронный метод"

_>2. Мы можем здесь добавить код (после END_ASYNC), который выполнится после первого асинхронного вызова, но до его завершения.

Опаньки ! Как все очевидно — в конце метода находится код который выполнится в начале

_>Да, но несмотря на все эти красивости я бы всё равно не стал писать так — мне не нравится подобный стиль реализации многопоточности.

Правильно, потому что отстой, о чем я и говорю.

I>>Красиво, это когда компилятор умеет связывание рахных сортов. В С# тоже можно все упаковать, притом используя именно поддержку компилятора.

_>Ну так мы и приходим к выводу что данная схема асинхронности одинаково легко реализуется и на C++ и на C#. Только в C# он жёстко зашит, а в C++ мы можем его подстроить под себя как хотим.

Ну тогда тебе не составит труда показать, чего же нельзя подстроить в C# и желательно что бы это было привязано к актуальной задача, а не выглядело навроде "а в конце метода я хочу что бы был код, который реально вызовется в начале"

Здравствуйте, alex_public, Вы писали:

I>>Не совсем понятно, где то расширяемость, если для каждого случая надо писать какой то уникальный код

_>Чёткое разделение кода и данных разных потоков в разных функциях. При такой схеме не надо продумывать что там куда может маршалиться или не может — всё сразу чётко видно.

У тебя всего лишь ручное разделение кода и данных. Проблемы с расширением возникают как раз из за ручного разделения, а не из за маршалинга. Странно что тебе пришла в голову мысль, что может быть необходимость маршалить чего то в рамках одного процесса

Здравствуйте, Ikemefula, Вы писали:

I>В винде любая такая софтина может нормально работать только как сервис. nginx на винде пока что ничем не блещет, потому что умеет только синхронные сокеты. И кстати говоря в планах асунуть его в сервис. Интересно, зачем, если и так всё шоколадно ?

А причём тут вообще винда и IIS? Вообще то подавляющее большинство веба живёт под разновидностями unix'a. Так что не надо кривых отмазок.

Ну и даже если говорить про винду (например в качестве машины разрабочика), то и nginx и apache тоже нормально работают без всяких сервисов.