Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.os.linux.programowanie > #2251

Re: ::read i ::poll

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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  |
`----------------------^--------------^---------------------^------------------'

Back to pl.comp.os.linux.programowanie | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

::read i ::poll heby <heby@poczta.onet.pl> - 2020-11-04 10:31 +0100
  Re: ::read i ::poll michal.lyszczek@bofc.pl - 2020-11-05 11:45 +0100
    Re: ::read i ::poll heby <heby@poczta.onet.pl> - 2020-11-05 12:57 +0100
      Re: ::read i ::poll michal.lyszczek@bofc.pl - 2020-11-05 13:43 +0100
        Re: ::read i ::poll heby <heby@poczta.onet.pl> - 2020-11-05 15:26 +0100
          Re: ::read i ::poll michal.lyszczek@bofc.pl - 2020-11-05 16:01 +0100
            Re: ::read i ::poll heby <heby@poczta.onet.pl> - 2020-11-05 19:16 +0100

csiph-web