Re: io assumptions

===
----- Original Message -----
From: "Henrik Nordstrom" <hno@squid-cache.org>
To: "Robert Collins" <robertc@squid-cache.org>
Cc: "Squid Dev" <squid-dev@squid-cache.org>
Sent: Thursday, December 05, 2002 12:38 PM
Subject: Re: io assumptions

> Not sure how you end up in this.
>
> Either the open/create is syncronous, in which case NULL should be
> returned, or it is asyncronous and there won't be a close callback
until
> the event queues are polled, which they won't be while the return is
> executing as there is a single main thread in Squid..

'should be' != IS. And the rest is what I am saying :].

storeDiskdOpen for instance, if the diskd shmget fails, cleans up the
request and returns NULL - inficating a failure. If the request is
queued, then yes it currently returns after the next io loop. BUT:
overlapped IO (or any OS-callback based IO) could potentially callback
immediately if the file metadata is in cache - breaking the current calling code.
Another example: storeUfsOpen returns NULL on open failure, an object on
open success.
And storeAufsOpen returns NULL to shed IO load, and an object that can
have reads queued - but that may not actually open successfully - if the
request gets queued.

So the calling logic ends up something like this:

storeIOState *foo = storeOpen ()
/*=== the below block should be in a 'opensuccessful callback' */
if (!foo)
  {
    HandleFailure();
    return;
  }
foo->read();
}

me::onClose()
{
   if (failure())
     HandleFailure();
}

In short:
NULL means open could not be queued (diskd/coss/aufs) or open failed (ufs).
object + close callback on next loop means open failed (diskd/coss/aufs).

I think we would be better served by:
* void return type.
* open always calls back, with error (failure of some sort) or good object (success on open).
* And the callback is allowed to occur immediately.

Rob