Re: apt https method v2

[Tomas Pospisek <tpo_deb@sourcepole.ch>]

On Fri, 5 Apr 2002, Jason Gunthorpe wrote:

> I'm not convinced that introducing the new Connection class instead of
> changing the semantics of CircleBuf is really best. Seems to add alot of
> extra text all over the place. If you look at carefully, the only reason
> serverstate has the FD at all is so it can call select. It only needs the
> FD for this, and it does not need the other baggage.

Um. So what should I do with this Select salad? In the present http-cc
code it's taking in up to three Fds:

* STDIN
* the connection, to check for readable stuff and to check fof
  non-blocking write
* a Fd to check for non-blocking write

And you expect it to tell you who caused select to return.

IMO the situation as is is "just fine". If we want to have an
implementation that tries to stuff everything into objects (IMO a bit
for the sake of it) then we have to stomp forward and either reimplement
all the FD_WEIRDNESS optimally through some ConnectionHandleSet class
or to implement some awkward select method like f.ex:

// Check connection and wFd for non-blocking write and see whether
// there's something to read on the connection or on rFd.
//
// Returns a bitmap where:
//
// 1 - write will not block on connection
// 2 - write will not block on wFd
// 4 - read  will not block on connection
// 8 - read  will not block on rFd
//
ConnectionHandle::CheckPlentyOfFds(int rFd, int wFd);

Yummy.

An alternative would be to have s.th. like:

ConnectionHandle::GetFd()

that returns a filehandle on which we can play those select tricks.
This could be easily done but if we do that then we're only _acting_
like being OO.

IMHO let's not exagerate this OO game.
*t

-----------------------------------------------------------------------
     Tomas Pospisek
     sourcepole    -   Linux & Open Source Solutions
     http://sourcepole.com
     Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
     Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12
------------------------------------------------------------------------





-- 
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org