## c't-Projekte - Mailinglisten

[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

### Re: [ct-bot] delay

Absender: Timo Sandmann
Datum: Do, 12.07.2007 16:17:43
In-reply-to: <46962BF0.9040900@xxxxxxxx>
References: <792F4909-2A8F-479F-BF59-B665BAD6FD86@xxxxxxxxxxxxxxx> <46962BF0.9040900@xxxxxxxx>

    Hi,

    Am 12.07.2007 um 15:26 schrieb Benjamin Benz:

> `Genau wie bei jedem anderen Verhalten. Entweder ruft man es mit` `OVERRIDE` `auf, dann wir der Alte Wunsch gelöscht oder man ruft es mit` `NO_OVERRIDE`

>     auf, dann bekommt man eine Fehlermeldung, wenn es belegt ist.

    na ja, der erste Aufrufer schaut aber letztlich immer in die Röhre:

`Verwendet man OVERRIDE, kann er zwar abfragen, ob er unterbrochen` `wurde, wenn ja weiß er aber nicht, wie viel Zeit nun schon vergangen` `ist.` `Verwendet man NOOVERRIDE, wird beim Aufruf von bot_delay() erst die` `interne Datenstruktur (Wartezeit) überschrieben und dann abgebrochen,` `so dass der zweite Aufrufer einen Fehler bekommt, die Wartezeit des` `Ersten aber nicht mehr stimmt.` `(Vermutlich gibt's das Problem auch bei anderen Verhalten, aber da` `nach geäußerten Fahrwünschen keine weiteren mehr gestartet werden,` `ist das eher unproblematisch.)`

`IMHO müsste ein einmal gestartetes delay auch garantiert korrekt` `ausgeführt und jeder nachfolgende Aufrufer abgeblockt werden. Der` `kann dann so lange delay-Aufrufe "probieren", bis das delay-Verhalten` `frei ist. Dann hätte man zwar so eine Art Spinlock, aber es würde` `zumindest die Semantik vom delay-Verhalten stimmen.`

    Gruß Timo

- Antworten:
  - Re: [ct-bot] delay
    - From: Benjamin Benz

- Referenzen:
  - [ct-bot] delay
    - From: Timo Sandmann
  - Re: [ct-bot] delay
    - From: Benjamin Benz

- Voriger (Datum): Re: [ct-bot] delay, Benjamin Benz
- Nächster (Datum): Re: [ct-bot] delay, Benjamin Benz
- Voriger (Thread): Re: [ct-bot] delay, Benjamin Benz
- Nächster (Thread): Re: [ct-bot] delay, Benjamin Benz
- Indizes:
  - Datum
  - Thread