Длительная работа с большим объемом данных на C++

Это как напишешь. :)

Программа может хоть месяц читать из порта и писать в файл.

Программа может хоть месяц читать из порта и писать в файл

Когда файл вырастет до 400-500 Мб, запись в него не будет тормозить?

Когда файл вырастет до 400-500 Мб, запись в него не будет тормозить?

В общем случае - нет.

Все будет хорошо.

В общем случае

А можно конкретики?

Хотелось бы знать не зависнет ли программа, когда накопится много данных?

не зависнет, если течь не будет.

У меня нет возможности протестировать все заранее.

сделайте эмуляцию: вместо rs-232 читайте файл. Да хоть /dev/urandom например.

Когда файл вырастет до 400-500 Мб, запись в него не будет тормозить?

нет. Если использовать O_APPEND, то можно хоть 100Гб и больше.

А можно конкретики?

ну если вы делаете mmap(2), то конечно будет уныло. В 32х битной системе так вообще больше 2Г не замапить. Ну а с вашими 2Г так вообще.

PS: Read The Fucкing Manuals

man 2 open

man 2 write

man 3 fopen

man 3 fwrite

man 2 mmap (вам этого не нужно, но почитайте для общего развития)

У меня нет возможности протестировать все заранее.

что программа должна работать непрерывно, в течении 2-х часов

Вранье.

Спасибо за развернутый ответ.

sudo cast Eddy_Em

Зачем зовешь меня в игноротред?

Только зачем использовать С++? С не хватает?

Объясни человеку, что там Сишки хватит

Я не программист, использую то с чем знаком. Работать с rs-232 я умею при помощи Qt, вот и выбрал связку C++ и Qt.

sudo cast Eddy_Em

нужно срочно сказать «C++ говно»?

Объясни человеку, что там Сишки хватит

там и brainfuck'а хватит. Это не повод менять ЯП.

Я не программист, использую то с чем знаком. Работать с rs-232 я умею при помощи Qt, вот и выбрал связку C++ и Qt.

Qt это всего лишь обёртка, что-бы уметь работать с обёрткой, нужно понимать содержимое.

для чтения из /dev/ttyS0, обработки и записи в файл не нужно ничего особого громоздить

что-бы уметь работать с обёрткой, нужно понимать содержимое.

вот это сейчас мощно было

для чтения из /dev/ttyS0, обработки и записи в файл не нужно ничего особого громоздить

ну видишь — ТС осилил только qtшные обёртки. Хотя конечно достаточно лишь fread(3) для этого.

C++ фобия какая-то.

А на системах, где нет /dev/ttyS0 и /dev вообще?

да не - микроскопом гвозди бить не удобно

use int14h!

На первый взгляд - никакого зависания быть не должно. Если начнутся траблы, то они будут сугубо индивидуальны. Думаю, никто даже из опытных прогеров не скажет тебе, где «стелить соломку».

Где тут микроскоп и где гвозди? Всё используетс по назначению. Qt давно перестал быть фреймворком для гуйни.

Проблем в общем-то начаться не должно.

Но как варианты оптимизаций (ради оптимизаций): разбивать файл на куски, всё это дело сразу же архивировать gzip'ом, например. Для экономии места на диске.

Qt давно перестал быть фреймворком для гуйни

Вот и я говорю - микроскопом по гвоздям =)

да не - микроскопом гвозди бить не удобно

Qt это не микроскоп, а скорее кувалда.

Надо заметить, что мы не знаем, что именно пишет топикстартер. Возможно чтение из ком порта - это только малая часть.

Возникла необходимость написать простую программу, которая будет считывать данные по rs-232 и записывать их в файл.

считывать данные по rs-232 и записывать их в файл

считывать, записывать

cat /dev/ttyS0 > out тогда уже

Слишком теоретизированные вопросы. Все зависит от логики твоей программы, которую мы не видим.
Можешь протестировать, эмулируя работу com-порта программно, например как советуют тут.

с использованием QtSerialPort

учти, что QSerialPort, как бы это помягче, глюковат и не всегда работает правильно, особенно с виртуальными драйверами

Ахах... Программа годами может это делать... не только лишь месяц :)

Начнем с того, что вообще ничего писать не надо.

cat /dev/ttyS0 > ./myfile

выше уже говорили:

Надо заметить, что мы не знаем, что именно пишет топикстартер. Возможно чтение из ком порта - это только малая часть.

учти, что QSerialPort, как бы это помягче, глюковат и не всегда работает правильно, особенно с виртуальными драйверами

Неужели? А баг-трекер начто? П###ть знаете-ли не мешки ворочать. (С)

А может так:

учти, что shty, как бы это помягче, глюковат и не работает правильно, особенно с QSerialPort ? :)

<Qt-фанбои набежали, все на велосипед>

Неужели? А баг-трекер нечто?

простите, лично Вы какой опыт работы с железками вообще и с последовательными портами в частности имеете?

:)) http://www.prog.org.ru/topic_9537_0.html

1) я правильно понимаю, что я таки могу посмотреть в глаза профиль человеку, отвественному за race condition (по всей видимости) в QSerialPort? :)

2) таки все же было бы интересно узнать про опыт работы с железками и выполнения проектов

1) я правильно понимаю, что я таки могу посмотреть в глаза профиль человеку, отвественному за race condition (по всей видимости) в QSerialPort? :)

Нет бага в трекере/форуме - нет и проблемы. Какой нафиг race condition в классе, который reentrant и не поддерживает многопоточие?

2) таки все же было бы интересно узнать про опыт работы с железками и выполнения проектов

10 лет, устроит?

Нет бага в трекере/форуме - нет и проблемы.

кому как

Какой нафиг race condition в классе, который reentrant и не поддерживает многопоточие?

1) reentrancy в данном случае не играет роли
2) эээ, простите, а event loop в случае асинхронной работы как организован?

2) таки все же было бы интересно узнать про опыт работы с железками и выполнения проектов

10 лет, устроит?

надеюсь в таком разе мне не надо объяснять, что если есть две одинаковые тестовые программы, одна из которых использует native api, а вторая QSerialPort и первая работает нормально, а вторая жует и слепляет данные, то наверное во второй программе что-то не так?

Кстати а что лучше для подобных целей QtSerialPort или Boost::asio, при учловии что гуй не нужен?

2) эээ, простите, а event loop в случае асинхронной работы как организован?

Сорцы открыты - берем и читаем.

надеюсь в таком разе мне не надо объяснять, что если есть две одинаковые тестовые программы, одна из которых использует native api, а вторая QSerialPort и первая работает нормально, а вторая жует и слепляет данные, то наверное во второй программе что-то не так?

Нет. Это означает что с кодером что-то не так, раз он не осилил такую банальщину.

Кстати а что лучше для подобных целей QtSerialPort или Boost::asio, при учловии что гуй не нужен?

Буст поменьше ресурсов ЦПУ жрет. Когда то делал сравнение. Пока не понятно почему такие результаты (хотя некоторые мысли есть на этот счет). Нужно как-нить сесть и заняться этим вплотную.

Отсюда выводы делайте сами. ;)

2) эээ, простите, а event loop в случае асинхронной работы как организован?

Сорцы открыты - берем и читаем.

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

Это означает что с кодером что-то не так, раз он не осилил такую банальщину.

у меня то как раз все работает как надо, а вот QSerialPort что-то не очень

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

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

Там нет тредов (платформу WinCE не берем в расчет).

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

Я не желаю слушать ниочем. Есть претензии - вперед на баг-трекер с примером чтобы воспроизвести проблему. Нет примера - не о чем разговаривать. Все очень просто.