pthread og sleep
Steinar Midtskogen
angitt antall sekund? L�sninger med sleep() eller signal() fungerer
d�rlig i tr�der. Kontekst er Linux, men noenlunde portbarhet skader
ikke.
Jeg f�r noe til � virke noenlunde med fork(), men jeg liker ikke den
l�sninga.
--
Steinar ; NIL DIFFICILE VOLENTI ; http://latinitas.org ; http://voksenlia.net
Hallvard B Furuseth
> Fins det noen elegant m�te � f� en tr�d (pthread.h) til � sove i et
> angitt antall sekund? L�sninger med sleep() eller signal() fungerer
> d�rlig i tr�der. Kontekst er Linux, men noenlunde portbarhet skader
> ikke.
POSIX sier at sleep() skal virke med tr�der. Men det er jo mulig Linux
bommer. Har sett r�d om � bruke nanosleep() i stedet, men den er visst
ogs� eldre enn POSIX-tr�der - men nyere enn sleep, s� kanskje det er
st�rre sjanse for at det virker.
Ellers finnes pthread_cond_timedwait() hvis det passer seg � bruke den.
Denne tar som argument tidspunktet du skal vente til i stedet for hvor
lenge � vente, s� man kan kalle den flere ganger i en ventel�kke om det
trengs.
--
Hallvard
Steinar Midtskogen
> Steinar Midtskogen writes:
>> Fins det noen elegant m�te � f� en tr�d (pthread.h) til � sove i et
>> angitt antall sekund? L�sninger med sleep() eller signal() fungerer
>> d�rlig i tr�der. Kontekst er Linux, men noenlunde portbarhet skader
>> ikke.
>
> POSIX sier at sleep() skal virke med tr�der. Men det er jo mulig Linux
> bommer. Har sett r�d om � bruke nanosleep() i stedet, men den er visst
> ogs� eldre enn POSIX-tr�der - men nyere enn sleep, s� kanskje det er
> st�rre sjanse for at det virker.
Det st�r i man-sida at sleep() kan v�re implementert med SIGALRM, og
signalbehandlinga er felles for alle tr�dene. Derfor har jeg ikke
fors�kt sleep(). Det st�r ikke noe om hvordan nanosleep() kan v�re
implementert.
> Ellers finnes pthread_cond_timedwait() hvis det passer seg � bruke den.
Jo, kanskje. M� tenke ut hvordan det da m� bli.
Dag-Erling Smørgrav
> Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
> > Linux bommer. Har sett råd om å bruke nanosleep() i stedet, men den
> > er visst også eldre enn POSIX-tråder - men nyere enn sleep, så
> > kanskje det er større sjanse for at det virker.
> Det står i man-sida at sleep() kan være implementert med SIGALRM, og
> signalbehandlinga er felles for alle trådene.
Jeg er fristet til å sitere en Dilbert-stripe: "Here's a nickel, kid.
Get yourself a real computer." (dvs. et OS som implementerer sleep()
uten å bruke signaler, og som har separat signalhåndtering for hver
tråd)
> Derfor har jeg ikke forsøkt sleep(). Det står ikke noe om hvordan
> nanosleep() kan være implementert.
nanosleep() er et systemkall i Linux.
Ellers har man alltid det gamle trikset med select():
int
mysleep(time_t seconds)
{
struct timeval tv = { seconds, 0 };
return (select(0, NULL, NULL, NULL, &tv));
}
Returnerer -1 og setter errno til EINVAL hvis angitt tidsperiode er
ugyldig (f.eks. negativ) eller EINTR hvis select() ble avbrutt.
DES
--
Dag-Erling Smørgrav - d...@des.no
Steinar Midtskogen
> Steinar Midtskogen <ste...@latinitas.org> writes:
>> Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
>> > POSIX sier at sleep() skal virke med tr�der. Men det er jo mulig
>> > Linux bommer. Har sett r�d om � bruke nanosleep() i stedet, men den
>> > er visst ogs� eldre enn POSIX-tr�der - men nyere enn sleep, s�
>> > kanskje det er st�rre sjanse for at det virker.
>> Det st�r i man-sida at sleep() kan v�re implementert med SIGALRM, og
>> signalbehandlinga er felles for alle tr�dene.
>
> Jeg er fristet til � sitere en Dilbert-stripe: "Here's a nickel, kid.
> Get yourself a real computer." (dvs. et OS som implementerer sleep()
> uten � bruke signaler, og som har separat signalh�ndtering for hver
> tr�d)
sleep() ser ut til � virke under min Linux, men jeg er usikker p� om
POSIX krever dette.
>> Derfor har jeg ikke fors�kt sleep(). Det st�r ikke noe om hvordan
>> nanosleep() kan v�re implementert.
>
> nanosleep() er et systemkall i Linux.
>
> Ellers har man alltid det gamle trikset med select():
>
> int
> mysleep(time_t seconds)
> {
> struct timeval tv = { seconds, 0 };
> return (select(0, NULL, NULL, NULL, &tv));
> }
Til min bruk er dette en helt ok m�te � gj�re det p�. Takk!
(Det jeg skriver er for �vrig noe som med jamne intervall poller ymse
ting fra ulike kilder. Kildene kan v�re over nettverk, fra filer,
eller fra hardware og kildene er ikke alltid tilgjengelige. Jeg deler
derfor programmet opp i en tr�d per kilde, slik at en utilgjengelig
kilde (som blokkerer videre kj�ring) ikke p�virker �vrig polling).
Bjørn Mork
>>> signalbehandlinga er felles for alle trådene.
>>
>> Get yourself a real computer." (dvs. et OS som implementerer sleep()
>> tråd)
>
> sleep() ser ut til å virke under min Linux,
Ja. Ref http://www.gnu.org/software/hello/manual/libc/Sleeping.html :
"On the GNU system, it is safe to use sleep and SIGALRM in the same
program, because sleep does not work by means of SIGALRM."
> men jeg er usikker på om POSIX krever dette.
Nei. Ref http://kerneltrap.org/man/linux/man3p/sleep.3p :
"There are two general approaches to the implementation of the sleep()
function. One is to use the alarm() function to schedule a SIGALRM
signal and then suspend the process waiting for that signal. The other
is to implement an independent facility. This volume of IEEE Std
1003.1-2001 permits either approach. "
Bjørn
--
You're always totally wrong
Steinar Midtskogen
> Steinar Midtskogen <ste...@latinitas.org> writes:
>
>> men jeg er usikker p� om POSIX krever dette.
>
> Nei. Ref http://kerneltrap.org/man/linux/man3p/sleep.3p :
>
> "There are two general approaches to the implementation of the sleep()
> function. One is to use the alarm() function to schedule a SIGALRM
> signal and then suspend the process waiting for that signal. The other
> is to implement an independent facility. This volume of IEEE Std
> 1003.1-2001 permits either approach. "
Men sier POSIX noe om hvordan signalhandtering skal foreg� i tr�der?
Dag-Erling Smørgrav
> Men sier POSIX noe om hvordan signalhandtering skal foregå i tråder?
Ja, se f.eks. pthread_kill() og pthread_sigmask().
Dag-Erling Smørgrav
> (Det jeg skriver er for øvrig noe som med jamne intervall poller ymse
> ting fra ulike kilder. Kildene kan være over nettverk, fra filer,
> eller fra hardware og kildene er ikke alltid tilgjengelige. Jeg deler
> kilde (som blokkerer videre kjøring) ikke påvirker øvrig polling).
Er det noen grunn til at du ikke kan bruke poll() eller select() til
dette?
Steinar Midtskogen
> Steinar Midtskogen <ste...@latinitas.org> writes:
>> (Det jeg skriver er for �vrig noe som med jamne intervall poller ymse
>> ting fra ulike kilder. Kildene kan v�re over nettverk, fra filer,
>> eller fra hardware og kildene er ikke alltid tilgjengelige. Jeg deler
>> derfor programmet opp i en tr�d per kilde, slik at en utilgjengelig
>> kilde (som blokkerer videre kj�ring) ikke p�virker �vrig polling).
>
> Er det noen grunn til at du ikke kan bruke poll() eller select() til
> dette?
Pollinga skjer via et bibliotek jeg ikke har til hensikt �
reimplementere, og jeg har ikke kontroll p� timeout.