crossplatform.ru

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


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

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

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


Последние 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 Текстовая версия Сейчас: 29.3.2024, 5:06