2012-05-10 37 views
6

Tôi có một số mã gọi recv() theo định kỳ (với cờ MSG_DONTWAIT). Tôi tò mò vì profiling mã của tôi trong vtune, tôi thấy một cuộc gọi sigprocmask() liên kết với các recv(), và nó chiếm một phần lớn trong tổng thời gian để thực thi. Tôi tò mò tại sao recv() đang gọi sigprocmask().Tại sao sigprocmask được gọi khi gọi đến hệ thống gọi lại?

+0

Chúng ta có thể thấy dấu vết có liên quan của mã nhỏ nhất có thể tái tạo hành vi này không? Chúng ta có thể thấy mã demo đó không? Nó sẽ được chiếu sáng để xem chính xác những gì đang được thực hiện cho mặt nạ tín hiệu. – pilcrow

+0

Bạn có thể giải thích về ngữ cảnh của những lời gọi đó đến 'recv()' không? Bạn đang sử dụng loại ổ cắm nào? Bạn đang gọi 'recv()' trực tiếp? – alk

Trả lời

0

Có lẽ do đó recv có thể cho biết các tín hiệu có liên quan được tạo ra nếu không sẽ không được nhìn thấy nếu các tín hiệu đã bị chặn. EAGAIN/EWOULDBLOCK đến tâm trí như là giá trị của errno đôi khi được tạo ra bằng cách sử dụng tín hiệu có thể có thể bị chặn. Bạn có nhìn vào số sigprocmask man page không?

+1

EAGAIN là mã lỗi, không phải là tín hiệu. – pilcrow

+0

Brainfart, tôi có nghĩa là lỗi. Cảm ơn. Lỗi đôi khi được tạo dựa trên các tín hiệu được xử lý. – JimR

1

Khi làm việc với TCP socket dưới Linux, bạn sẽ nhận được SIGPIPE nếu mặt kia bị đóng bất ngờ.

Vì bạn có thể che dấu tín hiệu này (hầu hết thời gian, bạn sẽ tự động xử lý giá trị trả về là 0, bạn không quan tâm đến tín hiệu này), tôi đoán kiểm tra thư viện hệ thống cho trạng thái tín hiệu, và nếu được đeo mặt nạ, hãy sử dụng đường dẫn mã nhanh hơn.

Nếu không, nó không thể tối ưu hóa.

BTW, bạn biết về pselect() phải không?

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