Tengo un código que llama a recv() periódicamente (con un indicador MSG_DONTWAIT). Tengo curiosidad porque el perfil de mi código en vtune, veo una llamada sigprocmask() asociada con el recv(), y está tomando una gran parte del tiempo total para ejecutar. Tengo curiosidad por qué recv() está llamando sigprocmask().¿Por qué se llama sigprocmask al llamar a la llamada al sistema recv?
Probablemente tan recv puede decir si se generan señales relevantes que de otro modo no se verían si dichas señales se bloquearan. EAGAIN/EWOULDBLOCK vienen a la mente como valores de errno que a veces se generan usando señales que posiblemente podrían bloquearse. ¿Miraste el sigprocmask man page?
Al trabajar con socket TCP en Linux, recibirá SIGPIPE si el otro lado se cierra inesperadamente.
Dado que puede enmascarar esta señal (la mayoría de las veces, manejará el valor de retorno de 0 usted mismo, esta señal no le importa), I supongo la biblioteca del sistema verifica el estado de la señal, y si está enmascarado, use una ruta de código más rápida.
De lo contrario, no se puede optimizar.
Por cierto, usted sabe acerca de pselect() ¿no?
¿Podemos ver un rastro relevante del código más pequeño posible que reproduzca este comportamiento? ¿Podemos ver ese código de demostración también? Sería esclarecedor ver exactamente qué se está haciendo con la máscara de señal. – pilcrow
¿Podría explicar el contexto de esas llamadas a 'recv()'? ¿Qué tipo de socket estás usando? ¿Estás llamando 'recv()' directamente? – alk