>GObject

Значит проблема глубоко в ГТК. Ибо нефиг делать ООП на языке, который его не поддерживает.

Мыши.
Кактус.

не зря нокия гтк выкидывает.

>Ибо нефиг делать ООП на языке, который его не поддерживает.

Если такой умный, может и Линусу это объяснишь?

сейчас придёт мужик2 и объяснит тебе, что так и нужно, а кто дёргает ползунок громкости, тот лох

>ДОКОЛЕ?????!!!1

До тех пор, пока десктопный софт будут писать студенты. Разве где-то в мануалах написано, что g_object_set_property потокобезопасный?

>Если такой умный, может и Линусу это объяснишь?

Linus и нетбуки, дубль два?

да, у меня на Убунту 64бит это стабильных баг, что ритмбоксовый звук во время воспроизведения менять == падение.

Все гуевые API с которыми я имел дело всегда были однопоточные, т.е везде все проперти меняются только в контексе треда обработки сообщений.

До тех пор, пока десктопный софт будут писать студенты. Разве где-то в мануалах написано, что g_object_set_property потокобезопасный?

Читаем мануал:

The functions g_object_ref/g_object_unref respectively increase and decrease the reference count.These functions are thread-safe as of GLib 2.8.

А теперь читаем последний багрепорт:

Various structures are refcounted in an unsafe way. This makes multithreaded applications fail at random. The most notable cases are signal emision (which refcounts various objects) and GObject refcounting.

Как говорится, ОПАНЬКИ!

и надо дергать не ползунок громкости а пинус, он то точно не упадет от этого

>не зря нокия гтк выкидывает.

От С++ - одни проблемы, так что зря.

Все гуевые API с которыми я имел дело всегда были однопоточные, т.е везде все проперти меняются только в контексе треда обработки сообщений.

Насколько я понял, в ритмбоксе падает не GUI, а какая-то часть gstreamer'а - gstobject, сделанный на основе gobject.

>Насколько я понял, в ритмбоксе падает не GUI, а какая-то часть gstreamer'а - gstobject, сделанный на основе gobject.

GTK - это все таки гуевый тулкит.

А теперь читаем еще раз:

>which refcounts various objects

Чтобы наглядно продемонстрирвать, спрошу: если a++ и b-- являются атомарными операциями, то разве это значит, что перенос единички из b в a будет атомарным: b--; a++ (или a++; b--)?

>Значит проблема глубоко в ГТК. Ибо нефиг делать ООП на языке, который его не поддерживает.

В стандарт C++ многопоточность не входит вообще. И что?

GTK - это все таки гуевый тулкит.

А glib - нет =).

>Если такой умный, может и Линусу это объяснишь?

ЛОЛШТО. Покажи мне ООП в ядре. Для ядра C - идеальный язык. Также для консольных и, скорее, несетевых утилит.

перенос единички из b в a будет атомарным: b--; a++ (или a++; b--)?

А ты уверен что перенесется та самая единичка, а не другая? Иначе все это фуфел.

>И что?

И ничего.

>А glib - нет =).

glib расчитана на асинхронную однопоточную модель выполнения программ. И если программист хочет сделать какие-то треды-воркеры, то они должны общаться с основным потоком при помощи эвентов.

Покажи мне ООП в ядре.

А ты исходники то посмотри =).

Все единички в процессоре подключены к одному VCC, а значит, что все они - воплощение одной Единицы.

>А ты уверен что перенесется та самая единичка, а не другая?

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

А теперь читаем еще раз:

which refcounts various objects

Во первых: и что с того? Тем более, что в том контексте, в котором понимаешь эту фразу ты, ИМХО правильнее было бы написать different а не various...

Во-вторых: ты это в каком мануале читаешь?

facepalm.patch...

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

> Покажи мне ООП в ядре

struct address_space_operations;
struct inode_operations;
struct file_operations;
struct inode;

Продолжать?

Открыл рандомный файл исходников, с копирайтом Линуса. Вижу чистый C без всяких извращений.

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

Плюс ещё VFS чуть более чем полностью.

Qt наше все!

ох щас срач-то будет...

Даже как-то не знаю... Наверное, я чего-то не понимаю... Нашёл struct inode, на вид так обычный себе сишный структ, предназначенный для объединения множества данных под одним именем...

Убунту 10.04 - не падает.

Убунту 10.04 - не падает.

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

УМВР. ЧЯДнТ?

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

В чем отличия вот этих двух фрагментов?

struct inode * my_inode = [...];
my_inode->i_fof->read(my_inode,buffer,count);

inode * my_inode = [...];
my_inode->i_fof->read(buffer,count);

Найди три отличия

Нашёл struct inode, на вид так обычный себе сишный структ

Нашел быдлокодера на ЛОРе. На вид обычный такой дурак...

> на вид так обычный себе сишный структ
В GObject тоже используется вполне себе C, что не мешает ему воплощать ООП. Надо же ж смотреть, как оно работает.

Длительно использую rhythmbox (c ~ 2005 года) и сразу скажу - штуки типа firefox на порядок чаще падают, а что rhythmbox *иногда* падает при изменении громкости - не припомню такого что-то , увы.
Ради интереса в Debian Lenny где-то сотню менял уровень регулятором громкости в rhythmbox.

fix:где-то сотню менял -> где-то сотню раз менял ))

>Во-вторых: ты это в каком мануале читаешь?

От тредсейфности учета ссылок? Это в документации по GObject идет. Там даже отдельно рассматривают копирование или что-то в этом духе, когда надо сначала увеличивать счетчик у нового объекта, и только потом уменьшать у старого.

Я нашёл, про что ты говоришь. Но та структура хранит в себе только ссылки на функции и, очевидно, нужна для того, чтобы к каждому inodу привязать функции специфичные именно для той фс, где он находится, и предоставить единый прозрачный интерфейс.

Понятно, что это очень похоже на ООП, но ООП не является.

А в GLib на C городят именно ООП с классами и прочим.

Fellrond сказал:

Убунту 10.04 - не падает.

Спасибо, кэп. Если бы у всех подряд падало - наверное бы уже починили давно.

>В чем отличия вот этих двух фрагментов?

Второй read — это static-функция или кривой сиплюсплюс!

>Понятно, что это очень похоже на ООП, но ООП не является.

ООП — это не ключевые слова class/virtual/public/private/etc. ООП — это подход. Поймешь, когда вырастешь большой и умный.

а кто дёргает ползунок громкости, тот лох

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

ну так
http://packages.debian.org/changelogs/pool/main/e/eglibc/eglibc_2.10.2-5/chan...

http://packages.ubuntu.com/eo/source/karmic/eglibc

Ну вот, а мужик-2 мне не верил.. :)

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

>А в GLib на C городят именно ООП с классами и прочим.

Это ты klass имеешь ввиду? :))