Реально ли выполнить метод класса в отдельном потоке?

Нужно сделать метод, callback на который ты передаешь в pthread, статическим. Одним из параметров в этот метод передавать this. Далее в этом методе вызывать this->method(params).

Большое спасибо! Все работает :)

> Нужно сделать метод, callback на который ты передаешь в pthread, статическим. Одним из параметров в этот метод передавать this. Далее в этом методе вызывать this->method(params).

зачем так сложно? не проще передать this как аргумент pthread_create и из потока уже вызвать this->my_method()? если нужно вызвать метод с параметрами - заверните их на пару с this в структуру.

// wbr

Я, собственно, то же самое и сказал :)

Функцию для потока логично объявлять статическим членом класса, т.к. она к нему отностися.

Можно было бы boost:thread воспользоваться , там все очень просто .

> Можно было бы boost:thread воспользоваться , там все очень просто .

boost::threads() всем хорош, но есть одно но: через их API нельзя управлять размером стека, который выделяется под создаваемый поток. пока потоков сравнительно мало (десяток-другой) это не есть большая проблема, но если вдруг их становится много (сотни/тысячи) то тут без стека никуда бо банально исчерпывается виртуальное адресное пространство процесса.

// wbr

>boost::threads() всем хорош, но есть одно но: через их API нельзя управлять размером стека, который выделяется под создаваемый поток. пока потоков сравнительно мало (десяток-другой) это не есть большая проблема, но если вдруг их становится много (сотни/тысячи) то тут без стека никуда бо банально исчерпывается виртуальное адресное пространство процесса.

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

boost::thread нельзя убить, приостановить и продолжить. Уж лучше простой pthread_*.

> boost::thread нельзя убить, приостановить и продолжить. Уж лучше простой pthread_*.

> boost::thread нельзя убить, приостановить и продолжить. Уж лучше простой pthread_*.

вы про pthread_cancel()? а оно надо?

// wbr

>>вы про pthread_cancel()? а оно надо?

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

Что то у меня вызывает мало радости использовать такую махину как boost только для тредов. :)

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

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

// wbr

> Что то у меня вызывает мало радости использовать такую махину как boost только для тредов. :)

ну вообще-то, это лишь маленький и сравнительно независимый кусочек от boost.

// wbr

boost это не одна библиотека, а много маленьких :)

[root:alex ~]$ apt-cache depends libboost-thread1.33.1
libboost-thread1.33.1
  Зависит: libc6
  Зависит: libgcc1
  Зависит: libstdc++6

[root:alex ~]$ apt-cache show libboost-thread1.33.1 | grep Size
Installed-Size: 104
Size: 33148

А-а...я и не знал :) Тогда пощупаемс.

> но если вдруг их становится много (сотни/тысячи) то тут без стека никуда бо банально исчерпывается виртуальное адресное пространство процесса.

Можно вопрос? Зачем нужны тысячи thread'ов? Исполняющих устройств (процов/ядер) на доступном железе будет ну максимум 8. Тысячи thread'ов будут либо все вместе спать (тогда какой смысл их плодить?), либо выполняться одновременно и выпихивать друг друг из L1/L2 кешей...

Почему нельзя писать в небольшое число тредов? Сделайте очередь обработки заданий, и 2*n_cpus thread'ов должно хватить.

Или вы API пользуетесь cинхронными и эти тысячи тредов висят в этих API и ждут ответов от каких-то удаленных систем?

> Или вы API пользуетесь cинхронными и эти тысячи тредов висят в этих API и ждут ответов от каких-то удаленных систем?

ну например :) причём изменить используемый синхронный API под асинхронную схему работы возможности нет, исполняемый им запрос может исполняться весьма долго (сложный запрос в базу) и одновременных запросов может быть мягко говоря много (десятки/сотни тысяч).

// wbr