2013-05-29 19 views
7

Tôi đang cố gắng hiểu toàn bộ quá trình nội bộ của Qt và cách nó hoạt động khi tôi làm việc với các luồng khác nhau.Qt Main-Gui và các chủ đề + sự kiện khác vòng

Như tôi đã hiểu (googling và khám phá mã nguồn Qt), là như sau:

  • Mỗi thread có "chờ xử lý danh sách sự kiện" địa phương và một vòng lặp sự kiện địa phương (nếu tôi gọi để exec) tương tác với danh sách đó.
  • QCoreApplication::postEvent(obj, e) nối cặp (obj, e) vào "danh sách sự kiện đang chờ xử lý" của chuỗi của obj.
  • Mỗi chuỗi có một "điều phối sự kiện" địa phương (QAbstractEventDispatcher chuyên môn), mục đích là đọc sự kiện hệ thống. Vì vậy, nó tồn tại một QEventDispatchWin, một QEventDispatchUnix, một QEventDispatchSymbian v.v., cho các nền tảng khác nhau. Đối với gui sự kiện, Qt có cũng QEventDispatchX11 (thừa hưởng từ QEventDispatchUnix), S60 (từ Symbian) vv

Với tất cả điều này trong tâm trí, một cuộc gọi exec hoạt động như sau:

Thread's `exec`: 
├ create a QEventLoop object. 
└ call QEventLoop.exec() 
    └ call repeatedly eventDispatcher's processEvents with WaitForMoreEvents flag. 
    ├ call to QCoreApplication::sendPostedEvents 
    ├ while (!pending system events) 
    │ ├ read system event 
    │ ├ create an appropiate QEvent e and detect its target QObject o. 
    │ └ call to QCoreApplication::sendSpontaneousEvent(o, e) 
    └ call to QCoreApplication::sendPostedEvents 
     (for new generated user events in the previous step). 

Nếu quit hoặc exit được gọi, nó kết thúc cuộc gọi processEvents hiện tại và exec trả về với giá trị được chuyển đến exit.

Một số điểm để mất trong việc xem xét:

  1. Hệ thống các sự kiện không bao giờ đẩy/đăng: khi chúng được tạo ra từ hệ thống và dịch là QEvents, họ đang sended trực tiếp đến đối tượng mục tiêu của nó.
  2. Chức năng thành viên đối tượng mục tiêu (o.event()) được gọi trong cùng một chuỗi nơi processEvent diễn ra.

Và bây giờ, nghi ngờ:

  1. Kể từ postEvent là một hàm tĩnh và thread-safe, vai trò gì QCoreApplication chơi trong hệ thống xử lý sự kiện này? Và QApplication? Tại sao chúng bắt buộc phải được tạo càng sớm càng tốt?
  2. Tại sao QApplication/QCoreỨng dụng là bắt buộc để nhận sự kiện hệ thống, nếu mỗi Chủ đề có "điều phối sự kiện" riêng của mình?

Bất kỳ sửa chữa nào về sự ủng hộ của tôi đều được hoan nghênh.

Trả lời

2

Để trả lời câu hỏi thứ hai của bạn, "Tại sao QApplication/QCoreApplication là bắt buộc để nhận sự kiện hệ thống, nếu mỗi Chủ đề có" điều phối sự kiện "riêng của mình?"

Các trạng thái 4.8 documenation:

"Lưu ý rằng QCoreApplication :: exec() phải luôn được gọi từ các chủ đề chính (thread thực thi main()), chứ không phải từ một QThread Trong các ứng dụng GUI. , thread chính cũng được gọi là thread GUI vì nó là luồng duy nhất được phép thực hiện các hoạt động liên quan đến GUI."

Nhưng về QThreads nói chung -. Bạn sẽ tìm thấy các liên kết được cung cấp mô tả QThreads như QObjects đó là một wrapper xung quanh chủ đề Vì vậy QThreads, giống như bất kỳ QObjects khác, đòi hỏi sự QCoreApplication để tương tác với để phối hợp thông báo/sự kiện, ví dụ như khi kết thúc chủ đề.

http://qt-project.org/forums/viewthread/14806

trong bài viết Maya, cô đưa ra một ví dụ trong đó nhiệm vụ được giao cho một QThread thay vì được định nghĩa trong [tức là tín hiệu sử dụng/khe và không quá tải phương thức run(): Bằng cách này, bạn thấy rõ ràng rằng vòng lặp sự kiện chính được cung cấp bởi QCoreAppli cation vẫn đóng một vai trò quan trọng. Như bạn có thể đã biết, đã có một lượng thảo luận dồi dào xoay quanh chủ đề của QThreads trên trang này - và Qt4 được viết khá tốt ... không thể nói tương tự cho Qt5 = (

+1

Xin lỗi vì đã đánh dấu câu trả lời của bạn là câu trả lời quá muộn. Tôi đã không nhận ra nó cho đến hôm nay. –

Các vấn đề liên quan