crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в QThread, QEvent, QTcpServer
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
Теги
Выровнять по центру
Ссылка на тему
Ссылка на сообщение
Скрытый текст
Сокращение
Код с подсветкой
Offtopic
 
Удалить форматирование
Спец. элементы
Шрифт
Размер
 
Цвет шрифта
 
Отменить ввод
Вернуть ввод
Полужирный
Курсив
Подчеркнутый
 
 
Смайлики
Вставить изображение
Вставить адрес электронной почты
Цитата
Код
Раскрывающийся текст
 
Увеличить отступ
По левому краю
По центру
По правому краю
Вставить список
Вставить список

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
ViGOur Дата 20.11.2008, 20:21
 
Цитата(512es @ 20.11.2008, 16:59) *
тут немного ни о том речь))
Понятно, вам выбирать принцип работы... :)
512es Дата 20.11.2008, 16:59
  тут просто разные нужды. мне важно чтобы все юзвери ансинхронно получали и отправляли маленькие пакеты. без задержек и очередей на приём\отправку. и оно отлично работает когда на каждого отдельный поток.

хотя я и планирую иногда передавать от сервера к юзверем файлы не больше 1 мб, это не файлообменник, где можно экономить на времени отклика, выстраивая отправку\приём в очередь.
вот наверное поэтому я всё никак с вами не соглашусь =))

32 соединения в поток, 320 соединений, это не 320 потоков, а 10, разница есть?

ХР может спокойно работать с 2032 потоками. 2000 пользователей меня вполне устраивают =) каких то особых тормозов от создания\удаления потоков или поедания памяти я не вижу. а ещё рассчёт на многопроцесорные машины на мноого лет вперёд))))

Цитата(ViGOur)
Цитата(512es)
а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)

Вот и я об этом же, потому и рекомендую экономить ресурсы, и повесить хотя бы по 32 соединения в поток, а не 1.

тут немного ни о том речь))
1) есть много много потоков, по 1 на юзверя (с низким приоритетом)
2) есть главный поток в котором очередь обработки (логика)

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

вот и всё =)
ViGOur Дата 20.11.2008, 15:21
 
Цитата(512es @ 20.11.2008, 13:52) *
а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)
Вот и я об этом же, потому и рекомендую экономить ресурсы, и повесить хотя бы по 32 соединения в поток, а не 1. :)

32 соединения в поток, 320 соединений, это не 320 потоков, а 10, разница есть?
512es Дата 20.11.2008, 13:52
  ViGOur, провёл эксперимент:
подключился двумя клиентами. один из них отправлял файл на 200 мб а второй быстро посылал маленькие пакеты серверу и получал ответ. пока файл отправлялся подключился ещё двумя клиентами и тоже быстро отсылал небольшие пакеты. задержек вообще никаких не наблюдалось!) всё работало так, какбудто 200 меговый файл и не принимался.
разве что, когда закончилась передача файла и он поступил в главный поток для обработки (в данном случае для записи на диск), отсылка ответов клиентам приостановилась ненадолго. но все пакеты скапливались в очередь и сразу обработались как только запись файла завершилась =)
а если такие большие пакеты посылать в отдельный специальный поток, с низким приоритетом то вообще хоть терабайты пересылать можно, никто и не заметит =)
ViGOur Дата 15.11.2008, 10:28
 
Цитата(Litkevich Yuriy @ 15.11.2008, 1:29) *
Ну вот, а на пргорге тема о высоконагруженном сервере на Qt зашла в тупик
Просто они не в ту сторону смотрели... :)

512es, и все же я тебе рекомендую попробовать в одном потоке держать несколько подключений.
Попробуй сделать одно оооочень медленное (например передачу огромного файла), и после этого 5-10 быстрых соединений, посмотри как они обработаются... ;)
Litkevich Yuriy Дата 15.11.2008, 1:29
 
Цитата(512es @ 15.11.2008, 4:19) *
вообще сервер работает быстро и надёжно) сколько бы не подключалось клиентов, пакеты им приходят моментально!)
Ну вот, а на пргорге тема о высоконагруженном сервере на Qt зашла в тупик (тык)
512es Дата 15.11.2008, 1:19
  разве что от CxThread::drawText() удалось избавиться)

emit thread[n].drawText().m_pPrint.drawText()


вообще сервер работает быстро и надёжно) сколько бы не подключалось клиентов, пакеты им приходят моментально!)
отказался от эвентов, использую везде теперь только сигнал\слот =)
ViGOur Дата 13.11.2008, 18:01
 
Цитата(512es @ 13.11.2008, 16:42) *
ViGOur, спасибо!) то что надо!))
Не за что, обращайся еще... ;)

Цитата(512es @ 13.11.2008, 16:42) *
жаль что нельзя упростить..
Можно.
512es Дата 13.11.2008, 16:42
  ViGOur, спасибо!) то что надо!))
у меня рождалась мысль что объект надо создавать в секции run() но уже не верилось что это заработает..
вообще жудко запутаная конструкция получилось, жаль что нельзя упростить.. хотяя...
ViGOur Дата 13.11.2008, 14:30
  Вот я пример набросал, правда с рисованием, но думаю идея будет понятна... :)
Раскрывающийся текст
main.cpp
#include <QtCore/QCoreApplication>

#include "xThread.h"

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    CxThread thread[2];
    for( int n=0; n < sizeof( thread)/sizeof( *thread); ++n)
    {
        thread[n].start();
    }

    while( true)
    {
        for( int n=0; n < sizeof( thread)/sizeof( *thread); ++n)
        {
            if( thread[n].isRunning())
                emit thread[n].drawText();
        }
        thread[0].sleep( 1);
        qDebug( "**********************");
    }

    return a.exec();
}

xThread.h
#ifndef XTHREAD_H
#define XTHREAD_H

#include <QThread>
#include <QMutex>

class CxPrint;

class CxThread : public QThread
{
    Q_OBJECT

private:
    static QMutex m_mutex;
    int        m_n;
    CxPrint *m_pPrint;

public:
    CxThread(QObject *parent=0);
    ~CxThread();

    void drawText();
    static void sleep ( unsigned long uls);
    int GetN()const { return m_n; }

protected:
    virtual void run();
    
};

class CxPrint: QObject
{
    Q_OBJECT

public:
    void drawText();

signals:
    void signalDrawText();

protected slots:
    void slotDraw();

public:
    CxPrint(void);
    virtual ~CxPrint(void);
};


#endif // XTHREAD_H

xThread.cpp
#include "xThread.h"
#include "xPrint.h"

QMutex CxThread::m_mutex;

CxThread::CxThread(QObject *parent)    : QThread(parent)
{
    m_n=0;
    m_pPrint = 0;
}

CxThread::~CxThread()
{
    delete m_pPrint;
    m_pPrint = 0;
}

void CxThread::drawText()
{
    if( m_pPrint)
        emit m_pPrint->drawText();
}

void CxThread::sleep ( unsigned long uls)
{
    QThread::sleep( uls);
}

void CxThread::run()
{
    {
        QMutexLocker locker(&m_mutex);
        static int n = 1;
        m_pPrint = new CxPrint;
        qDebug( "Runing thread with id: 0x%x, thread N: %d", QThread::currentThreadId(), n);
        m_n = n;
        n++;
    }

    CxThread::exec();
}

CxPrint::CxPrint(void)
{
    connect( this, SIGNAL( signalDrawText()), this, SLOT( slotDraw()));
}

CxPrint::~CxPrint(void)
{
}

void CxPrint::slotDraw()
{
    qDebug( "Draw in thread with id: 0x%x, thread N: %d", QThread::currentThreadId(), ((CxThread*)QThread::currentThread())->GetN());
}

void CxPrint::drawText()
{
    emit signalDrawText();
}
Просмотр темы полностью (откроется в новом окне)
RSS Рейтинг@Mail.ru Текстовая версия Сейчас: 8.7.2025, 15:09