Re: fileevent saying there's something to read but there isn't ?!

On 25 May 2006 13:40:41 -0500, rugger@xxxxxxxxxxxx (Kip Rugger) wrote:

David Gravereaux <davygrvy@xxxxxxxxx> wrote:
Yet who is the responsible party to develop that event that the
fileevent callback requires?


There are two ideas of operating-system design in play here.

First, how is synchronization done? There are several models that
have emerged over the years:

- n-way wait (Unix select(2), MVS ecb lists)

- event lists (BSD kqueue(2), QNX mailboxes, Tcl, X event protocol)

- callbacks (Windows).

Secondly is the basic concept that flow control must be exercised by
the upstream client -- you tell the client that data can be read
rather than forcing the client to accept the actual data itself; the
client actively accepts the data when resources permit.


The fileevent behaviour is a byproduct of the early n-way wait
primitives. After the wait is satisfied, you essentially poll the
underlying files for their status. This polling is stateless in the
sense that there is no attempt to prevent previously reported status
from being reported again. That is source of the familiar
read-ready/EOF infinite loops that incorrect scripts can experience.

By contrast, the event-list primitives tend naturally not to
re-report. Indeed re-reporting would cause chaos for events such as
mouse clicks, etc. In general you can think of events as being a
vehicle for maintaining a slave copy of a master data-structure -- the
event stream reports the changes to the master so that they can be
replicated in the slave. (Of course this is an abstract
data-structure; its contents are specified but not its format.)


The case at hand is a layering problem: at what layer of the channel
implementation should the translation from n-way semantics to event
semantics occur. Because this translation is not desirable for
anything but files (and even there only for historical reasons), I
would suggest that the answer is that the caller of CreateEventSource
would be the highest layer at which it could logically occur. Or
perhaps a CreateFileeventSource service that implements the polling
behaviour.


I am now experiencing that rant feeling :)


Thanks Kip. So that's where that behavior comes from.. Now I'm
thinking about maintaining a second list of "eof, but unclosed"
sockets to query [count != 0] in the Tcl_EventSetupProc. That should
do it as I won't have to manufacture things as the polling to it Tcl
already provides.

Thanks.
.

Relevant Pages

  • no doubt Lenerss striped tear
    ... revival may divert more jails. ... tender node is the client that reports especially. ...
    (sci.crypt)
  • Architecture question
    ... Fairly complex, PCU-intensive reports acessed monthly ... DB server and the network, but the super-expensive reports I think are ... too much to ask a central server and the company's network. ... required on the client machines to generate them (rather than a saved ...
    (microsoft.public.dotnet.general)
  • Re: Client inventory encryption
    ... I will worry about the "unable to verify client ......". ... >> out that report to my secondary site are reporting in correctly....I am ... >>> If the reports are being rejected, it could be that the MP for the ... >>> I think your problem is not encryption but DDR processing. ...
    (microsoft.public.sms.inventory)
  • Web service client, with embedded web server for SOAP callbacks - need clear guidance
    ... I am working on an industrial application that reports data from industrial ... I am working to an industry standard interface spec, ... I have to develop a client to receive the data. ... defines a data collection plan (creates local object, ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • SMS Push deployment
    ... SMS Clients poll the SMS server for the new advertisement. ... In SMS server,"Advertisement Programs Client Agent" we can configure ... Suppose the polling interval is 60 min. ...
    (microsoft.public.sms.swdist)