Russian Qt Forum

Qt => Пользовательский интерфейс (GUI) => Тема начата: Fregloin от Сентябрь 18, 2012, 11:20



Название: Можно ли "заморозить" слот/сигнал?
Отправлено: Fregloin от Сентябрь 18, 2012, 11:20
Можно ли заморозить определенный слот/сигнал у виджета?
Есть комбобокс. К сигналу currentIndexChanged(int index) привязан слот, который обновляет таблицу нужными элементами.
При заполнении  комбобокса через addItem(), этот слот вызывается каждый раз при добавлении нового элемента, что вызывает излишние расходы на обновления таблицы.
setUpdatesEnabled ничего не дает. Сигналы/слоты связаны на этапе проектирования в дизайнере.
есть ли возможность как то заморозить сигнал на время, что бы он не испускался определенное время, например при заполении комбобокса? или только вручную connect/disconnect  в нужные моменты?


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 18, 2012, 11:27
Код
C++ (Qt)
bool QObject::blockSignals ( bool block )


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Fregloin от Сентябрь 18, 2012, 14:57
спасибо


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 18, 2012, 18:04
blockSignals() заморозит все сигналы, поэтому с ним надо осторожно обращаться. Я обычно использую флажок вместо блокировки сигнала и в слоте проверяю этот флажок.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Akon от Сентябрь 18, 2012, 22:22
я за connect/disconnect  в нужные моменты


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 19, 2012, 10:45
connect/disconnect - это поиск строки (пока Qt5 не вышло), что есть не всегда оптимально.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Akon от Сентябрь 19, 2012, 13:32
Да, но для гуя вся эта скорость неактуальна.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 19, 2012, 15:46
Да, но для гуя вся эта скорость неактуальна.
Ню-ню.
Тролли тоже видимо так думали, когда связывали вью с моделью через сигналы.
В результате имеем тормоз при больших таблицах.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Akon от Сентябрь 19, 2012, 15:59
Вы серьезно полагаете, что это из-за сигналов и слотов?


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Bepec от Сентябрь 19, 2012, 18:38
Да, именно из-за сигналов и слотов :)

Потому соответственно приходится сигналы сажать на цепь :)


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 20, 2012, 11:02
На исполнение сигналы, вроде бы, не сильно тормозят. Только коннект и дисконнект относительно медленный.

Хотя в случае топикстартера, конечно, этим временем можно пренебречь.

Вот еще есть такая штука, как альтернатива блокировки сигналов -
http://www.prog.org.ru/topic_15938_0.html


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Авварон от Сентябрь 21, 2012, 08:06
Bepec
Практика показала, что тормозят не сигнал\слоты, а перерассчеты во вьюхе, отрисовка, и, как это ни странно, реаллоки в списке с данными. Советую поглядеть в профилировщике. Ну и да, инсертить в модель чаще чем 25 раз в секунду не имеет смысла:) Группируйте обновления модели.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Bepec от Сентябрь 21, 2012, 09:12
Несогласен с вами :) % на 70.

Конечно тормоза вытекают из обработок, которые вызываются из слотов, вызываемых сигналами :) Но и сигналы тоже не быстры :)

PS про 25 секунд и сам дошёл давно уже :) Это проходил каждый :D


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Авварон от Сентябрь 21, 2012, 12:07
Зря не согласны. У нас есть модель, в к-ой 2 миллиона строк (!) и постоянно добавляются новые строки. Еще раз - реаллок и/или меммув, вызванные инсертом/ремувом, занимает времени больше (во много раз), чем вызов слота, сконнекченного с сигналом. Особенно, если пользовать стандартные QList\QVector:) Проверено профайлером 20 раз.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 12:19
Еще раз - реаллок
Для не владеющих сленгом столичной молодежи - не могли бы Вы пояснить кто такой "реаллок"?

Особенно, если пользовать стандартные QList\QVector:)
Да, где-то с миллиона элементов сладкая жизнь с простыми контейнерами кончается (и это правильно :))


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Bepec от Сентябрь 21, 2012, 12:34
Аваррон вы немного путаете :)

Я говорю о том, что сигналы медленные по сравнению с прямыми вызовами :)

Вы же сравниваете сигнал и вызов слота с последующей обработкой данных модели, что в корне неверно :)

PS если дальше пойдёт, то начнёте сравнивать скорость работы класса с его конструктором :D

PPS реаллок - наверно освобождение памяти :)


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Пантер от Сентябрь 21, 2012, 13:06
реалок - перераспределение памяти.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Akon от Сентябрь 21, 2012, 13:30
Верес:
Да потрудитесь проанализировать предыдущие посты, особенно ваши, может поймете, кто путается.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Авварон от Сентябрь 21, 2012, 13:54
Аваррон вы немного путаете :)

Я говорю о том, что сигналы медленные по сравнению с прямыми вызовами :)

Вы же сравниваете сигнал и вызов слота с последующей обработкой данных модели, что в корне неверно :)

PS если дальше пойдёт, то начнёте сравнивать скорость работы класса с его конструктором :D

PPS реаллок - наверно освобождение памяти :)

Понятно, что прямые вызовы будут быстрее, чем сигнал\слот. Но зачем экономить на спичках, если есть гораздо более проблемные вещи?

Igors
реаллок - это сишная функция realloc(). Странно, что вы не знаете:)


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 14:21
Igors
реаллок - это сишная функция realloc(). Странно, что вы не знаете:)
Эту знаю, то Ваша транскрипция/прононс меня сбили с толку :) В свое время намучался с ней
Код
C++ (Qt)
void * data = malloc(1024 * 1024 * 100); // выделили 100 Mb
data = realloc(data, 1024);  
 
Блок 1K корректен, но по крайней мере "на некоторых платформах" 100Mb остаются занятыми. Писал Qt об этом, поблагодарили (наверное пофиксили).

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


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Авварон от Сентябрь 21, 2012, 15:34
Igors
реаллок - это сишная функция realloc(). Странно, что вы не знаете:)
Эту знаю, то Ваша транскрипция/прононс меня сбили с толку :) В свое время намучался с ней
Код
C++ (Qt)
void * data = malloc(1024 * 1024 * 100); // выделили 100 Mb
data = realloc(data, 1024);  
 
Блок 1K корректен, но по крайней мере "на некоторых платформах" 100Mb остаются занятыми. Писал Qt об этом, поблагодарили (наверное пофиксили).

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

Какая связь между сишными функциями и Qt??

Ну собственно самописная дека легко расширяется для вставки в середину. С появлением чанков уменьшаются накладные расходы на меммув при вставке в середину.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Sancho_s_rancho от Сентябрь 21, 2012, 15:48
Igors
реаллок - это сишная функция realloc(). Странно, что вы не знаете:)
Эту знаю, то Ваша транскрипция/прононс меня сбили с толку :) В свое время намучался с ней
Код
C++ (Qt)
void * data = malloc(1024 * 1024 * 100); // выделили 100 Mb
data = realloc(data, 1024);  
 
Блок 1K корректен, но по крайней мере "на некоторых платформах" 100Mb остаются занятыми. Писал Qt об этом, поблагодарили (наверное пофиксили).

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

Какая связь между сишными функциями и Qt??

Ну собственно самописная дека легко расширяется для вставки в середину. С появлением чанков уменьшаются накладные расходы на меммув при вставке в середину.

Qt-шники фиксят реализации плюсовых компиляторов и поведение ОС  :o
Пятница закончилась хорошим настроением. Спасибо.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 18:40
Какая связь между сишными функциями и Qt??
Довольно прямая. Попробуйте такой тестик на OSX 10.6.8.
Код
C++ (Qt)
#include <QVector>
 
int main ()
{
const int count = 100 * (1024 * 1024);
 
QVector <int> test;
test.resize(count);
 
printf("after resize, press enter\n");
getchar();
 
test.erase(test.begin(), test.begin() + count - 4);
 
test.squeeze();
 
printf("after squeeze, press enter\n");
getchar();
 
test.clear();
 
printf("after clear, press enter\n");
getchar();
 
return 0;
}
 
Обратите внимание что дока по squeeze обещает освободить память, однако на 10.6.8 этого не происходит, Activity Monitor по-прежнему показывает 400 Mb занято

Ну собственно самописная дека легко расширяется для вставки в середину.
Это интересно, прошу показать как. Хотя обычно если говорится "легко" - шансов увидеть маловато  :)


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 21, 2012, 18:47
Обратите внимание что дока по squeeze обещает освободить память, однако на 10.6.8 этого не происходит, Activity Monitor по-прежнему показывает 400 Mb занято
Память-то squeeze освобождает, только вот не отдаёт системе)
Всё зависит от реализации malloc-a.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 19:08
Память-то squeeze освобождает, только вот не отдаёт системе)
Всё зависит от реализации malloc-a.
Если напр в 32-бит я так буду "освобождать" - очень быстро получу отказ выделения. А в 64 пойдет по свапам что еще хуже. С malloc везде все хорошо, ни разу не видел его вины. А вот использования проблемной ф-ции realloc лучше избегать, это несложно


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 21, 2012, 19:27
Функция realloc не проблемная. Менеджеры памяти всегда отъедают память для кучи у системы и не всегда у них получается ее освободить. Посудите сами, к примеру, выделили вы 100Мб, а затем 100б, теперь вы 100Мб ужимаете до 1 килобайта, и получается дырка вочти в 100 Мб между двумя выделениями. Менеджер памяти не может при этом отдать эту память системе. Отдаст системе только когда вы освободите те последние 100 б. Но при этом память для приложения освободилась и менеджер памяти может переиспользовать ее для новых выделений.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 19:59
Но при этом память для приложения освободилась и менеджер памяти может переиспользовать ее для новых выделений.
Это легко проверить. Изменим примерчик
Код
C++ (Qt)
#include <QtGUI>
 
int main ()
{
const int count = 100 * (1024 * 1024);
 
for (int i = 0; i < 100; ++i) {
QVector <int> * test = new QVector <int> ();
test->resize(count);
test->erase(test->begin(), test->begin() + count - 4);
test->squeeze();
 
printf("after squeeze, press enter\n");
getchar();
}
 
return 0;
}
 
На OSX 10.6.8 увидим последовательное пожирание памяти 400, 800 и.т.д. Когда (в 32-битах) граница 2Gb будет перейдена - получим столь любимое Вами exception  :)


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Bepec от Сентябрь 21, 2012, 21:07
Эммм igors а где realloc? :)

Вы в примере тупо выделяете память :) Конечно она убьётся в эксепшн.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 21, 2012, 21:27
С malloc везде все хорошо, ни разу не видел его вины. А вот использования проблемной ф-ции realloc лучше избегать, это несложно
Не надо разделять malloc/realloc ибо они всегда являются частью одного менеджера памяти.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 21, 2012, 21:45
Эммм igors а где realloc? :)

Вы в примере тупо выделяете память :) Конечно она убьётся в эксепшн.
У кого убьется, а у кого и как сказать. Речь здесь о том что не везде realloc отдает память взад. В результате squeeze не работает как положено (см. обсуждение выше).

Не надо разделять malloc/realloc ибо они всегда являются частью одного менеджера памяти.
Я вполне согласен с этим глубокомысленным утверждением, но не пойму как оно меняет практический результат :). Это не только для QVector,  на и для др, напр QString, и разделяем мы там чего или нет - мне придется с этим считаться напр при работе с большими файлами


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 21, 2012, 23:03
Сейчас проверил на голых malloc и realloc - результат тот-же после 4х-5и итераций SIGSEGV.
Протрассировал исполнение:
Для выделения памяти используется системный вызов mmap2, для перевыделения mremap. Почему-то память ядром выделяется от больший адресов к меньшим, это и объясняет, почему каждый последующий вызов на 400 мб не влезает в оставшуюся дырку.

Цитировать
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x84fd2000
mremap(0x84fd2000, 419434496, 4096, MREMAP_MAYMOVE) = 0x84fd2000
write(1, "after squeeze, press enter 1\n", 29after squeeze, press enter 1
) = 29
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6bfd1000
mremap(0x6bfd1000, 419434496, 4096, MREMAP_MAYMOVE) = 0x6bfd1000
write(1, "after squeeze, press enter 2\n", 29after squeeze, press enter 2
) = 29
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x52fd0000
mremap(0x52fd0000, 419434496, 4096, MREMAP_MAYMOVE) = 0x52fd0000
write(1, "after squeeze, press enter 3\n", 29after squeeze, press enter 3
) = 29
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39fcf000
mremap(0x39fcf000, 419434496, 4096, MREMAP_MAYMOVE) = 0x39fcf000
write(1, "after squeeze, press enter 4\n", 29after squeeze, press enter 4
) = 29
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20fce000
mremap(0x20fce000, 419434496, 4096, MREMAP_MAYMOVE) = 0x20fce000
write(1, "after squeeze, press enter 5\n", 29after squeeze, press enter 5
) = 29
mmap2(NULL, 419434496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)

Так, что это не глюк Qt и даже не глюк malloc/realloc, это просто особенность выделения памяти ядром. Случай специфичный просто.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 22, 2012, 11:51
Не понимаю этих соображений насчет "дырок" - по-моему они давно стали историей, сейчас выделяется страницами и.т.д. (помню Вы сами отвечали на подобный вопрос).

Я столкнулся с этой проблемой лет 5 назад. Погуглив понял так что это не баг, такая реализация realloc допустима. Просто выкинул у себя все realloc заменив их на malloc + memmove, это работает везде. Спрашивал что на др платформах - хотя это уже "академический интерес". Вроде на Win7 все хорошо, а на каком-то др Вындоуз - то же самое. Когда вчера постил, мелькои проверил на OSX 10.7 - там все освобождается.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 22, 2012, 12:49
Может, чтобы не сталкиваться с этой проблемой, использовать один менеджер везде?
Тем более помнится Вам уже предлагали это сделать здесь (http://www.prog.org.ru/index.php?topic=10610.msg64082#msg64082).


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 22, 2012, 13:28
Может, чтобы не сталкиваться с этой проблемой, использовать один менеджер везде?
Тем более помнится Вам уже предлагали это сделать здесь (http://www.prog.org.ru/index.php?topic=10610.msg64082#msg64082).
Звучит типа "вот ведь какой бестолковый! Ему же предлагали.." :) А как я это сделаю? Полезу менять исходники Qt и буду повторять процесс с каждой новой версией? Как-то не тянет

Просто такая подлянка с realloc есть и знать о ней не помешает. А если действительно большие данные (гигабайты) то все равно лучше свой контейнер, ни std, ни Qt контейнеры не устроят. Поэтому проблема не так уж актуальна. 


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: GreatSnake от Сентябрь 22, 2012, 14:15
А как я это сделаю? Полезу менять исходники Qt и буду повторять процесс с каждой новой версией? Как-то не тянет
Зачем что-то менять ??? Достаточно просто "перегрузить" malloc/realloc/free на уровне библиотеки. Хотя бы через тот же LD_PRELOAD.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 22, 2012, 19:33
Нет никакой подлянки, я же расписал. Всё работает четко и предсказуемо. Просто надо менять способ работы с памятью. Или писать свой менеджер памяти, который такому поведению не подвержен. Но в большинстве случаев всё хорошо.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 22, 2012, 20:08
Нет никакой подлянки, я же расписал. Всё работает четко и предсказуемо. Просто надо менять способ работы с памятью. Или писать свой менеджер памяти, который такому поведению не подвержен. Но в большинстве случаев всё хорошо.
Ну вот Вам очередной примерчик. Запускаю (OSX 10.6.8 ), консоль радостно выдает ошибку. Ставлю USE_REALLOC  0, т.е. обхожу realloc, использую вместо него malloc + memmove. Все работает. Уже и размер блока взял пионерские 10 Mb - ну как же я все время не попадаю на то самое большинство случаев где все хорошо?  :)
Код
C++ (Qt)
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
#define USE_REALLOC 1
 
void * ReAlloc( void * addr, size_t size )
{
if (!addr) return malloc(size);
 
#if USE_REALLOC
return realloc(addr, size);
#else
void * blk = malloc(size);
memmove(blk, addr, size);
free(addr);
return blk;
#endif
}
 
int main ()
{
const int count = 10 * (1024 * 1024);
 
int i;
for (i = 0; i < 1000; ++i) {
void * test = malloc(count);
// void * test = malloc(count - i * 1024);   // можно и так, результат тот же
 
if (test)
test = ReAlloc(test, 4);
if (!test) {
printf("can't alloc/realloc\n");
break;
}
}
 
printf("steps done %d\n", i);
 
return 0;
}
 


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: DmitryM от Сентябрь 22, 2012, 21:04
Так, что это не глюк Qt и даже не глюк malloc/realloc, это просто особенность выделения памяти ядром. Случай специфичный просто.
Вроде как в Linux с glibc malloc работает через brk.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 22, 2012, 23:22
Ну вот Вам очередной примерчик. Запускаю (OSX 10.6.8 ), консоль радостно выдает ошибку. Ставлю USE_REALLOC  0, т.е. обхожу realloc, использую вместо него malloc + memmove. Все работает. Уже и размер блока взял пионерские 10 Mb - ну как же я все время не попадаю на то самое большинство случаев где все хорошо?  :)

Вот диаграмма с двумя способами realloc, надеюсь, разница будет понятна:
(https://docs.google.com/drawings/pub?id=1VAOLUh-oYw7WgOWvv-2YTeEPx38zqC7j7SsL4LaXNRU&w=600)
Если рисунка не видно - залогиньтесь в гугле 8)

Цитировать
Вроде как в Linux с glibc malloc работает через brk.
strace говорит о том, что память в линуксе выделяется с помощью mmap2. Что такое "brk" ?


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 23, 2012, 05:36
Вот диаграмма с двумя способами realloc, надеюсь, разница будет понятна:
Если рисунка не видно - залогиньтесь в гугле 8)
Рисунок видно, спасибо. Вопросы:

1) Oткуда взялось смелое предположение о непрерывном блоке? Страничный механизм уже не работает или как?

2) Хорошо, примем Вашу версию и будем распределять каждый новый блок меньше предыдущего (я добавил строчку в пример). Результат - отказ памяти, просто на неск шагов дальше. Как Вы это поясните?

3) Какая разница прикладной программе "почему" - факт налицо, с realloc получен отказ, заменив его - все норм. Зачем же отрицать что ф-ция проблемная и подлянка возможна? Объясняя "почему" Вы ведь тем самым признаете что факт имеет место  :)

Кстати какой у Вас ОС? (для коллекции/статистики проблемы)
Спасибо


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: navrocky от Сентябрь 23, 2012, 10:26
Виртуальная память выделяется непрерывным блоками.

У меня opensuse 12.1.

Попробуйте ваш пример с декрементом размера блока >=4096. Размер страницы 4096 байт на интелях.


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: DmitryM от Сентябрь 23, 2012, 16:47
strace говорит о том, что память в линуксе выделяется с помощью mmap2. Что такое "brk" ?
man sbrk (http://linux.die.net/man/2/sbrk), а в man malloc (http://linux.die.net/man/3/malloc)
сказано
Цитировать
Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).

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


Название: Re: Можно ли "заморозить" слот/сигнал?
Отправлено: Igors от Сентябрь 23, 2012, 20:21
Виртуальная память выделяется непрерывным блоками.
Ну "невиртуальной" давно уже нет, максимум можно рассчитывать на невыгружаемые страницы, да и то скорее всего на уровне ядра.

Когда-то пробовал разобраться (уже довольно давно) и понял так: для распределения большого блока вызывается vmalloc (OSX) который распределяет всегда целое число страниц и резервирует непрерывное дисковое пр-во. Мои попытки воспользоваться vmrealloc ни к чему не привели - уменьшить выделенный блок не удавалось, можно было только удалить. Пришел к выводу что некоторые ОС могут держать такие блоки и это место недоступно для др выделений из соображений непрерывности на диске.

Впрочем с точки зрения прикладной программы причина не так уж важна