🚀 go-pugleaf

On 2020-11-05 12:57:04, heby wrote:
> On 05/11/2020 11:45, michal.lyszczek@bofc.pl wrote:
> > Najprościej będzie wysłać sygnał do konkretnego wątku przy pomocy
> > pthread_kill(3).
> 
> Co z taką sytuacją:
> {
>  ...
>  std::mutex::scoped_lock lock(mutex);
>   ...
>  ::read(...)
> }

Nic, w takim przypadku nie pomoże pthread_kill(3) tylko select/poll/epoll.
> 
> Zakładając że zainstaluje globalny handler sygnałów (co już jest błędem
> projektowym, może nie tylko ten wątek go potrzebuje), czy mogę wsyłać coś co
> spowoduje że ::read wyskoczy z EINTR?

Globalny handler sygnałów nie jest błędem projektowym, błędne użycie go
jest błędem projektowym. Signal handler, którego jedyne zadanie to przerwać
syscall, może mieć jedynie 'return;' w body i nie musi operować na żadnych
danych. Każdy sygnał przerywa syscall, możesz wyemitować np. SIGUSR1. Ale
jeżeli kilka wątków czyta ci jeden deskryptor plików to musiałbyś się bawić
w zmienne w stylu "thread_id_in_read", i na tej podstawie słać sygnały - ale
to już zabawa w synchronizację.

read(2) nie jest przystosowany do wielowątkowego obsługiwania, lepiej byłoby
aby 1 wątek robił read(2) na fd, jakoś to wstępnie procesował, po czym
wrzucał na jakąś synchronizowaną kolejkę, która może już być odczytywana
przez wiele wątków.

t1:
    while (1) {
        struct data_frame frame;
        read_until_full_frame_is_received(&frame);
        queue_push(&frame);
    }

t2, t3, t4...:
    while (1) {
        struct data_frame frame;
        queue_pop(&frame);
        process_frame(&frame);
    }

W takim przypadku to nawet nie powinno być potrzeby bawić się w EINTR. Nie
znam konkretnego użycia więc też ciężko się odnieść do tego trochę.

> 
> > Jak kod ma być przenośny między unixami, należy
> > pamiętać by wyłączyć SA_RESTART na systemach z rodziny BSD przy
> > pomocy siginterrupt(3).
> 
> No i tu właśnie jest problem. To ogromna apliakcja. Z powodu kilku ::read
> mam manipulować krytyczm, globlanym stanem aplikacji? Brzmi jak 1 z
> kolokwium z inżynierii programowania.

Jak 1 z kolokwium to brzmi "To ogromna aplikacja" ;-) Dodatkowo, zmierzyłeś
że problem z wydajnością jest spowodowany przez select/poll? Jak masz tam
raptem kilka deskryptorów, to ciężko mi uwierzyć żeby to miało taki narzut
na wydajność i problem jest zapewne gdzie indziej. To, albo optymalizujesz
program na siłę.

Jak bardzo chcesz mieć nieblokujący read(2) oraz nie używać polla to możesz
zawsze ustawić przy pomocy fcntl(2) ustawić flagę O_NONBLOCK, i przy każdym
read(2) gdy nie będzie danych dostaniesz zwrotkę -1 oraz errno na EAGAIN.

-- 
.-----------------.-------------------.---------------------.------------------.
| Michal Lyszczek | Embedded C, Linux |   Company Address   |  .-. open source |
| +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 |  oo|  supporter  |
| https://bofc.pl `----.--------------: 50-078 Wroclaw, Pol | /`'\      &      |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:  813 349 58 78 |(\_;/) programer  |
`----------------------^--------------^---------------------^------------------'