Архитектура: парсинг и выгрузка текстовиков

начало было положено в ветке - Считать текстовые файлы из папки - там и возник вопрос об Архитектуре...

Сообщение от JeyCi так и не собрала эти все объекты этого класса в group class...

вроде уже собрала...
осталось отображение создать (типа I_tbl_Show) и пронаследовать ? в разные классы пункта назначения (или на консоль, или в файл, или в БД, или допустим ещё в форму)... N.B. классы (пункты-назначения) делать не надо - эти View уже реализованы разработчиками того ПО, на котором сейчас идёт работа...
а) пока что можно просто прописать функции-члены класса; и по месту использовать, что надо при разработке - в файл или на консоль;
б) в перспективе для Release - реализовать и откомпилировать и выгрузку и в файл, и выгрузку в БД, и отражение в DataGrid...
===
!! Т.Е. если в Release захочется и выгрузку в текст, и в БД, и допустим ещё в форму (например с разных кнопок сделать) - тут уж лучше и писать, как положено, наследование??... -- к слову из прошлой ветки о:

Сообщение от JeyCi полагаю тут Наследования никакого не пригодится?

... или как раз тут (при выборе направления выгрузки) его (наследование) делать??
===
Обоснование выбора уровня Абстракции (I_tbl_Show со всеми виртуальными функциями):
чтобы не дублировать код-сбора-для-выгрузки -- сделать class Table - и класс-интерфейс I_tbl_Show, в котором обозначить virtual-функции выгрузки... эти функции определить в др. классах - типа Interface (IwriteCSV, IwriteDB, IwriteDataGrid)...
p.s.
классы консоль, файл, бд, DataGrid - не создаём, т.к. эти пункты назначения уже присутствуют...
p.p.s.
вывести конечные интерфейсы с определёнными методами записи на кнопки...
===
ИЛИ то, что подчёркнуто чуть выше, стоит реализовать в одном классе Table, и здесь же задать все virtual функции ??
===
на скрине: синие - классы, зелёные - интерфейсы (в с++ по сути тоже классы)
птицами отмечены уже кое-как реализованные классы (2 птицы)
курсивные стрелки - отсутствие наследования


Добавлено через 7 минут
вобщем вопрос:
class Table и класс I_Tbl_Show - объединить или нет?

Добавлено через 10 минут
p.p.s.
чтобы избежать проблем Ромба и такого:
Неоднозначность при множественном наследовании

Сообщение от DrOffset Тут нужно виртуальное наследование.

0

Сообщение от DrOffset Наоборот он у вас НЕ блокирующий.

я имела ввиду instanceAsync.Get() метод...

Сообщение от DrOffset Это не ошибка, еще раз. Это статус

WhenDo тоже показался интересным событием...
а смутило - это

I couldn't find a way to asynchronously read incoming data with WebSocket

но раскручивать, действительно лучше как-то requests, чем websockets (последний не совсем то, лишь бы с асинхронностью не было так грустно в request'ах, как в последнем)...
array worker'ов
WorkQueue : public CoWork

Сообщение от DrOffset Скорее всего это происходит потому, что вы пытаетесь слать данные в неблокирующий сокет без какого-либо контроля, да еще и из разных потоков. Сделайте очередь запросов к сокету, в нее будете добавлять из произвольного потока, разматывайте очередь через select\poll\etc в каком-то одном потоке.

спасибо!...

0

Параллельное программирование на С++ в действии. Энтони Уильямс

Добавлено через 16 минут
и позаимствую ссылку от DrOffset, - О lockfree алгоритмах (+бонус)
или здесь (с одним producer'ом в моём случае, может, ещё и проще)

Добавлено через 23 минуты
и нюанс, который стоит помнить

более полезно ограничить размер очереди и таким образом сбалансировать скорость производителей, иногда переводя их в спящее состояние, с возможностями потребителей.

0

Сообщение от DrOffset При том, что дождавшись, они все ранво должны вызвать join, если в их системе под капотом потока, например, pthread.

Не должны. Здесь запускается detach-поток.

Сообщение от Ultimate++: C++ 1 static void Start(Function<void ()> cb, bool noshutdown = false) Starts a thread and returns immediately (you cannot Wait for the thread to finish in this case).

В коде JeyCi запуск потока происходит по-другому (создается объект Thread). И если там не вызвать Wait, то поток станет detach в деструкторе.

Сообщение от Ultimate++: C++ 1 ~Thread() Destructor. Performs Detach - thread continues running.

1

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

0

Сообщение от GoshaM Destructor. Performs Detach - thread continues running.

detach, думаю, не очень хорошо - отпускать ненужный поток в свободное плавание... даже, может, ненужная эксплуатация памяти и адресного пространства (если не закрывать join'ом) - мне так кажется... даже не знаю, где такое может пригодиться?
я бы закрывала все ненужные thread'ы... имхо... через совет от DrOffset - Wait()...
а определяется detach, наверно, такой опцией:

Сообщение от GoshaM bool noshutdown = false

- она, видимо, и определяет возврат в метод Start, а поток отправляет в detach состояние? (точнее метод)

0

Сообщение от JeyCi detach, думаю, не очень хорошо - отпускать ненужный поток в свободное плавание... даже, может, ненужная эксплуатация памяти и адресного пространства (если не закрывать join'ом) - мне так кажется... даже не знаю, где такое может пригодиться?

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

1

Сообщение от oleg-m1973 в пуле потоков, ... достаточно подождать, пока все потоки закончат выполнять твой код (для этого достаточно счётчика),

счётчика фьючей? - тогда, конечно, они возвращают своим .get(), туда, где породились, блокируя IO до момента возврата, насколько понимаю... иначе, наверно, просто счётчик не поможет отследить окончание работы в потоках пула... наверно, всё равно какой-нибудь типа completion port надо мониторить и возвращать результат работы, если пул потоков не с фьючей запущен асинхронно, а с обычных thread'ов

0

Сообщение от JeyCi даже не знаю, где такое может пригодиться?

Если вы вызываете Run у одного объекта Thread более одного раза без вызова Wait между ними, вы уже это делаете неявно:

Сообщение от JeyCi void MyAppWindow::btn1_Click() {     this->btn_1.Disable();     work.Run( [=]{WorkerThread ();} );     }

1

Сообщение от JeyCi счётчика фьючей? - тогда, конечно, они возвращают своим .get(), туда, где породились, блокируя IO до момента возврата, насколько понимаю... иначе, наверно, просто счётчик не поможет отследить окончание работы в потоках пула... наверно, всё равно какой-нибудь типа completion port надо мониторить и возвращать результат работы, если пул потоков не с фьючей запущен асинхронно, а с обычных thread'ов

Нет, просто счётчик запущенных потоков - увеличивается при запуске и уменьшается при завершении потока.
Проблема с join в том, что чтобы его сделать нужно где-то хранить ссылки на экземпляры потоков, в каком-то списке. Если потоки часто запускаются/завершаются - типичный сценарии для пула - надо как-то чистить этот список, а это не самая весёлая задача.

1

oleg-m1973, можно не останавливать потоки в пуле, а просто усыплять до получения новых задач. Все-таки старт-остановки потока - это достаточно тяжелые операции.

1

Сообщение от DrOffset oleg-m1973, можно не останавливать потоки в пуле, а просто усыплять до получения новых задач. Все-таки старт-остановки потока - это достаточно тяжелые операции.

Потоков может быть очень много.
Там обычно указывается количество постоянных потоков - тех, которые не завершаются, и количество потоков, которые выполняют задачи, пока они есть и, если задач нет, завершаются. В винде для пула по умолчанию это 1 и 500 соответственно.

0

Сообщение от oleg-m1973 Потоков может быть очень много.

Может. Только зачем?

0

Сообщение от oleg-m1973 Нет, просто счётчик запущенных потоков - увеличивается при запуске и уменьшается при завершении потока.

я примерно это и имела ввиду

Сообщение от JeyCi а можно и handler'ы на файлы мониторить, сравнивая с количеством handler'ов на на promises ...

- чтобы окончание подгрузки увидеть... реализация показалась сложной - не для моего уровня самостоятельного написания... может, дорасту когда...

0

Сообщение от DrOffset Может. Только зачем?

В смысле, зачем? Ну, например, обработка запросов по сокетам.

0

Сообщение от DrOffset Может. Только зачем?

мне грузить надо ~500 за день... при загрузке за, например, 5 дней - даже математику можно успеть вспомнить...

Добавлено через 5 минут

Сообщение от oleg-m1973 Ну, например, обработка запросов по сокетам.

но у меня он один, вроде, с 1-го моего пк (так сказать клиента)... хотя на серверах в U++ не очень весело... имхо...
вобщем ковыряю асинхронность... благо httpRequest.Do() позволяет выделять все phases query'я

0

Сообщение от JeyCi но у меня он один, вроде, с 1-го моего пк (так сказать клиента)... хотя на серверах в U++ не очень весело... имхо...

Это я просто привёл первый пример, который пришёл в голову. Пул потоков я тоже привёл для примера того, где можно использовать detach. Тебе необязательно всё это использовать

0

Сообщение от DrOffset Может. Только зачем?

а вообще резонный вопрос - если они будут стоять в очереди на ядро... :

0

Сообщение от oleg-m1973 В смысле, зачем?

Зачем их заводить больше, чем есть ядер? Особенно 500.

0

? поможет ли это потом сокету - эта многопоточность пула ... ускориться

Добавлено через 1 минуту

Сообщение от DrOffset Зачем их заводить больше, чем есть ядер?

вот тоже помню совет QuantityCores*2 т.е. текущие и следующие за ними jobs в очередь

Добавлено через 2 минуты
поэтому

Сообщение от JeyCi ковыряю асинхронность...

0

Сообщение от JeyCi а вообще резонный вопрос - если они будут стоять в очереди на ядро... :

Ели они выполняют какие-то ждущие задачи, например отправляют запрос в базу, работают с файлами, отправляют что-то по сокетам и т.д., то они не будут стоять в очереди на ядро. В основном они будут спать в ожидании завершения своей задачи.

1