Камышев Александр

Пользователи
  • Публикации

    225
  • Зарегистрирован

  • Посещение

  • Days Won

    8

Камышев Александр last won the day on 14 ноября 2016

Камышев Александр had the most liked content!

О Камышев Александр

  • Звание
    Продвинутый пользователь
  • День рождения 02.12.1978

Информация

  • Пол
    Мужчина
  • Город
    Москва, Троицк

Посетители профиля

649 просмотров профиля
  1. это и есть одна из реализаций пула потоков, смысл не создавать и уничтожать под каждую задачу поток, сразу создать несколько и использовать их многократно.
  2. имхо, с firemonkey неплохо работает такая схема: 1. создать две потокозащищенные очереди (структуры), на си для этого подходит std::deque, в fmx можно TList. Защита стандартно TCriticalSection; 2. создать несколько потоков, с помощью TEvent указать им ссылки на очереди и критические секции; 3. в потоках: 3.1 TCriticalSection::Enter лочим очередь задач, 3.2 забираем крайнюю задачу 3.3 TCriticalSection::Leave отпускаем очередь задач 3.4 вычисления 3.5 по аналогии с очередью задач лочим очередь результатов, выкладываем результаты, отпускаем 3.6 повтор с пункта 3.1 4. в основном потоке в очереди (тоже lock unlock) выкладывать задачи и при наличии результатов отрисовывать имеющимися средствами. в 4 пункте нужен будет нужен будет какой-нибудь mmtimer.
  3. while(1) Sleep(INT_MAX) - это грубо, но можно еще брутальней: while(1){} если так принципиально, для успокоения, можно создать еще поток, передать ему ссылку на event, добавить код event->SetEvent() и не запуская на выполнение уйти в WaitFor, тогда все в порядке: два потока, оба ждут.
  4. мдя согласен, счетчик только увеличивается тогда еще проще: TSimpleEvent *event = new TSimpleEvent(NULL); event->WaitFor( INFINITE ); замри
  5. по разному... как обезьяна с гранатой, куда швырнет, варианты от ничего и вплоть до краша
  6. deadlock? - легко: TCriticalSection *cs = new TCriticalSection(); cs->Enter(); cs->Enter();
  7. Unix то да, только до сих пор это были java приложения для виртуальной машины, теперь можно создавать исполняемые ELF файлы консольных приложений и библиотеки под unix. выше было видео, создание Apache dynamic link module, вот здесь c 45 минуты:
  8. The RAD Studio IDE now includes its first LLVM based Linux compiler for Enterprise development, enabling Delphi developers to target 64-bit Intel Linux servers and devices. The Linux compiler is certified for Ubuntu Server (LTS 16.04) and RedHat Enterprise (V7) and is built on top of the LLVM engine Они что, правда сделали компилятор под unix исходников на паскале? Или еще один переход си <-> паскаль? Насколько мне известно, модули для apache до сих пор собирали и устанавливали с помощью apxs / apxs2, apxs в свою очередь работает с исходниками на Си, объектными файлами *.o и статическими библиотеками *.a. И как все это хозяйство привязали к паскалю? Что-то, воля ваша, недоброе таится© в написании кода на си, который использует компоненты написанные на паскале, которые собираются компилятором(написанным видимо на си) в объектники и библиотеки, которые затем будут собраны в модули для демона написанного на си..., доколе? При этом, нет поддержки линукс-сервер для borland си... все, абзац.
  9. Полная ерунда - весомый довод... Сохранить то utf-8 можно, компилер среды BCCAARM.EXE, the C++ Compiler for Android все равно будет с ними работать как с asci, и также не поймет кириллицу, если ему, как писали выше, если не указать принудительно. А вот BCC32, the C++ Command-Line Compiler все считает корректно.
  10. Это все делает TLang стандартный, зачем переписывать доступные стандартные компоненты?
  11. Если строки в языковых файлах - зачем RTTI, что к чему безопасно runtime приводить? Почему бы Embarcadero не работать сразу с unicode, стандартно UTF-8(16)? RAD Studio работает с исходниками на Ansi, а компилятор не распознает кириллицу в этих исходных файлах, приведение: case 0: return (AnsiString)"Ожидание"; сделано как попытка объяснить компилятору, что это кириллица. Правильный подход (имхо опять же) - среде нужно сразу работать с unicode, и не извращаться потом с приведением типов.
  12. На Seattle это работает, не знаю уж как там преобразование в Android API, в Berlin уже нет. Приложение под Андроид оставил в Seattle и больше не заморачивался пока. Сейчас пишу демон TCP сервера на с++ под CentOs в среде NetBeans, там строки языка Ansi С и стандартные строки std::string из C++. Отображение строк только в логах либо в браузере и проблем с кириллицей нет.
  13. Некорректно выразился, на андроид не работает связка FireDac + MySQL, т.к. используется libmysql.dll, с sqLite все вроде ок.
  14. мдя, чудес не бывает, в базе и близко нет 3к записей в секунду, из-за ошибки с флагом наложение данных и до записи доходит процентов 10-20, потому и ресурсов мало потребляет.
  15. статистика: запросов задач в сек. 3000 подтверждений в сек. 0 параметры файлов в сек. 0 запросов данных в сек. 0 запросов клиента в сек. 0 время запроса, мсек. 156 активных соединений с бд 10 из 10 запросов в бд в сек. 3000 размер очереди в бд 1365 из 5000 время запроса к бд, мсек. 31 устройства 2490 профили 139 задачи 51 файлов доступно 11 db_client 0 запросов в сек. 300 db_client 1 запросов в сек. 302 db_client 2 запросов в сек. 300 db_client 3 запросов в сек. 300 db_client 4 запросов в сек. 301 db_client 5 запросов в сек. 300 db_client 6 запросов в сек. 300 db_client 7 запросов в сек. 298 db_client 8 запросов в сек. 299 db_client 9 запросов в сек. 300