разнести класс по потокам

аааааа замуровали демоны

Зачем здесь вообще класс?

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

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

ыыыы... а речь точно о Си++? :)

Делай один класс. "Не плоди сущности без нужды" (c)

>> в конструкторе, или отдельным методом?

Ну или так или так :)))

Искусство программирования для UNIX стр. 213 предпоследний абзац

"Комбинация параллельных процессов, интерфейсов удалённого вызова процедур и тяжеловестного объектно-ориентированного дизайна является особенно опасной... но от проектов, где предполагается использовать все три, следует решительно отказаться"

то есть советуете отказаться от объектно-ориентированой модели и переписать все на структурах??

> то есть советуете отказаться от объектно-ориентированой модели и переписать все на структурах??

Нет, всего лишь советуем не лепить объекты туда, где они не нужны. Например - какое внутреннее состояние будет у твоего объекта СыройСокет?

класс СыройСокет заводить не поанировалось. планировался класс, имеющий дескриптор сокета как данное, метод ПослатьПачкуДейтаграм и умеющий при этом все приходящее на сокет читать и нужное складывать себе в вектор результатов. дело в том, что этому же объекту надо вызывать метод ПолучитьВсеЧтоПришло, а при реализации в одном потоке это блокирует поток и вызов ПослатПачкуДейтаграм откладывается на неопределенное время. потому и спрашиваю совет - пилить на 2 класса(что не совсем удобно), или можно создать внутри класса поток, и в нем вызывать некоторые методы?

> класс СыройСокет заводить не поанировалось

Название неважно.

> планировался класс, имеющий дескриптор сокета как данное

То есть внутренние данные класса - ровно одно поле целого типа?

> метод ПослатьПачкуДейтаграм и умеющий при этом все приходящее на сокет читать и нужное складывать себе в вектор результатов.

Или вектор тоже является полем класса?

> потому и спрашиваю совет - пилить на 2 класса(что не совсем удобно), или можно создать внутри класса поток, и в нем вызывать некоторые методы?

"Я не могу ответить на твой вопрос в терминах Зодиака^WООП, ибо Зодиак^WООП не имеет к этому никакого отношения" (с)

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

class Pinger {
pthread_t thread;
Socket socket;
Cycle* cyclelist;
CycleResult * result;
Pinger();
Add(Cycle);
ExecCycle();
ReadSocket();
~Pinger();
}

Pinger::Pinger()
{
socket=.....;
thread =pthread_create(&ReadSocket, ...);
.....
}

int Pinger::ReadSocket
{
while(1)
{
read(socket);
...........
}
}

Pinger::~Pinger()
{
.....
pthread_exit(thread);
}

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

Нить, 2 прикрытых мютексом и condvar'ом vector'а, 1 дескриптор сокета. Это можно при желании обернуть в объект, но называть это "классом работы с сокетом" я бы не стал.

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

> а создавать вторую нитку лучше из главного потока

Я чего-то не понимаю в твоей задаче. Особенно фразу:

> основной поток мог бы работать с остальной частью класса как ему надо.

Что вообще требуется от пингера и каково его место в программе?

> или таки в конструкторе объекта?

Подозреваю, что в конструкторе.

от пингерра требуется через некоторые промежутки времени посылать пачку icmp-дейтаграм на указаный узел. причем каждый раз узел может быть разный. но при этом же он должен принимать все что приходит на raw-сокет. и выцеплять из этого нужные ответные данные - rtt и сетевые события/ошибки.

Ох шайтан-программа... делай как тебе удобно. Как поймёшь почему это неудобно - переделаешь.

Я бы сделал одним классом. А нафига структуру программы усложнять? - скоро каждую функцию в класс оборачивать будут. Там у тебя не так уж много внутренностей и концептуально всё это под один класс подходит (что умеет куда-то писать вполне может мочь оттуда и читать). А вообще ман KISS (принцип такой) и действуй соответственно.