---

Hej

Jeg er godt i gang med min socket bog samt hvad jegf kan finde på nettet.

Jeg har nu læst om hvordan deadlock opstår, men ikke rigtig kunen finde en
forklaring på hvordan man undgår dette. I min bog står der at man skal undgå
at sende samtidigt i begge retninger, men det kan ligesom ikke lade sig gøre
i praksis (f.eks. i en chat).

Nogen har har en praktisk forklaring/læsning?


--
/ morten

"There are only 10 types of people in the world: Those who understand
binary, and those who don't"

---

On Sun, 30 Mar 2003 00:38:40 +0100, Morten Winther wrote:

> Jeg er godt i gang med min socket bog samt hvad jegf kan finde på
> nettet.
>
> Jeg har nu læst om hvordan deadlock opstår, men ikke rigtig kunen finde
> en forklaring på hvordan man undgår dette. I min bog står der at man
> skal undgå at sende samtidigt i begge retninger, men det kan ligesom
> ikke lade sig gøre i praksis (f.eks. i en chat).
>
> Nogen har har en praktisk forklaring/læsning?

select()

mvh
socketd

---

"Socketd" <db@traceroute.dk> skrev i en meddelelse
> > Nogen har har en praktisk forklaring/læsning?
>
> select()

Så vidt jeg kan læse mig frem til kan deadlock godt fremkomme selv om du
bruger select.

Tænker du ikke på at man kan undgå blocking med select?

/ morten

---

On Sun, 30 Mar 2003 01:05:53 +0100, Morten Winther wrote:

> Så vidt jeg kan læse mig frem til kan deadlock godt fremkomme selv om du
> bruger select.
>
> Tænker du ikke på at man kan undgå blocking med select?

Som du skrev, har deadlock noget at gøre med at begge parter venter på
svar fra hinanden. Den bedste måde at løse dette er ved at aftale hvem der
siger noget hvornår. Du gav et eksempel med en chat, her skal du bruge
select(), så hvis forbindelsen er inaktiv i X antal minutter (fordi
ingen skriver), vil forbindelsen timeout (hvilket du også fanger med
select()).

mvh
socketd

---

Socketd <db@traceroute.dk> writes:

[snip]
> > Tænker du ikke på at man kan undgå blocking med select?
>
> Som du skrev, har deadlock noget at gøre med at begge parter venter på
> svar fra hinanden. Den bedste måde at løse dette er ved at aftale hvem der
> siger noget hvornår. Du gav et eksempel med en chat, her skal du bruge
> select(), så hvis forbindelsen er inaktiv i X antal minutter (fordi
> ingen skriver), vil forbindelsen timeout (hvilket du også fanger med
> select()).

Dvs. du kan fortaelle select hvor laenge du vil vente paa at der
sker noget paa en af de registrerede handles. Hvis intet sker
lukker forbindelsen ikke, men du kan vaelge at haandtere det som
timeout.

Det er heller ingen der siger at du skal bruge select(), det er
kun et foreslag. Du kan ogsaa bruge traade eller fork() og have
en laeser og en skriver.

Der burde ikke vaere noget i 'sockets' som er kan give deadlocks,
naermere i protokollen du impl. ovenpaa - men giv gerne et eksempel
der viser det modsatte .


Mvh,

--
___
Soren Davidsen / o\
Math student, ICSMA (_____)
__ http://www.tanesha.net/ _________________________________(___)_______

---

"Soren Davidsen" <soren200303@tanesha.net> skrev i en meddelelse
news:874r5lyzju.fsf@tanesha.net...

> Det er heller ingen der siger at du skal bruge select(), det er
> kun et foreslag. Du kan ogsaa bruge traade eller fork() og have
> en laeser og en skriver.
>
> Der burde ikke vaere noget i 'sockets' som er kan give deadlocks,
> naermere i protokollen du impl. ovenpaa - men giv gerne et eksempel
> der viser det modsatte .

I min bog beskrives det at hvis de 2 buffers SendQ og RecvQ størrelse er
mindre end størrelsen på det send() kaldes med, så vil send() ikke returnere
før der er plads nok i RecvQ hos modtageren. Dog kalder modtageren ikke recv
fordi den selv står og venter på en den anden buffer bliver ledig.

Hmm. Det er lidt svært at forklare. Men kan det så ikke blot løses ved at
lave en buffer der altid er stor nok?

/ morten




..

---

On Sun, 30 Mar 2003 12:31:06 +0200, Morten Winther wrote:

> I min bog beskrives det at hvis de 2 buffers SendQ og RecvQ størrelse er
> mindre end størrelsen på det send() kaldes med, så vil send() ikke
> returnere før der er plads nok i RecvQ hos modtageren. Dog kalder
> modtageren ikke recv fordi den selv står og venter på en den anden
> buffer bliver ledig.
>
> Hmm. Det er lidt svært at forklare. Men kan det så ikke blot løses ved
> at lave en buffer der altid er stor nok?

Dette løses ved at lave non-blocking sockets (i samarbejde med select()).

br
socketd

---

"Socketd" <db@traceroute.dk> skrev i en meddelelse

> > Hmm. Det er lidt svært at forklare. Men kan det så ikke blot løses ved
> > at lave en buffer der altid er stor nok?
>
> Dette løses ved at lave non-blocking sockets (i samarbejde med select()).

Ok, var blot ikke sikker på om man kunne bruge non-blocking sammen med
select.

/ morten

---

Morten Winther <mail@is.invalid> skrev:

> Ok, var blot ikke sikker på om man kunne bruge non-blocking sammen med
> select.

Det kan man, men select vil netop fortælle hvilke sockets som kan
kaldes uden at blokere så det er ikke nødvendigt at bruge
ikke-blokerende sockets med select.

Se i øvrigt også på poll som kan circa det samme som select.

---

On Sun, 30 Mar 2003 22:19:00 +0200, Byrial Jensen wrote:

> Det kan man, men select vil netop fortælle hvilke sockets som kan kaldes
> uden at blokere så det er ikke nødvendigt at bruge ikke-blokerende
> sockets med select.

Ikke helt korrekt. Hvis du med select() undersøger om en socket kan
skrives til vil du få et "ja" hvis modtagerens window-size er < 0 (det er
nok mere end 0 i praksis), men du ved ikke om modtagerens window-size er
mindre end det du ønsker at sende, og dermed kan du ikke vide om den vil
blokke.

mvh
socketd

---

On Sun, 30 Mar 2003 12:27:33 +0200, Soren Davidsen wrote:

> Dvs. du kan fortaelle select hvor laenge du vil vente paa at der sker
> noget paa en af de registrerede handles. Hvis intet sker lukker
> forbindelsen ikke, men du kan vaelge at haandtere det som timeout.

Jep, men vil TCP ikke også selv timeout på et tidspunkt?

> Det er heller ingen der siger at du skal bruge select(), det er kun et
> foreslag. Du kan ogsaa bruge traade eller fork() og have en laeser og en
> skriver.

Ja, hvis man fork()'er en process til hver klient, så går en deadlock kun
ud over den enkelte bruger, men i exsemplet med en chat vil dette være
overhead (meget endda).

mvh
socketd