Re: scalable event scheduling

From: Rainer Weikusat <rweikusat_at_mobileactivedefense.com>
Date: Thu, 31 Jan 2013 14:21:30 +0000

Alex Rousskov <rousskov_at_measurement-factory.com> writes:
> On 01/30/2013 06:30 PM, Amos Jeffries wrote:
>
>> BUT .... this is not the same project Rainer is working on (replacing
>> the engine, not the API).
>
> Please note that my sketch does not replace the existing event API, it
> only adds to it (just like Rainer's patch does).
>
> There were two primary changes in the patch that Rainer has posted:
>
> A) An event queue engine replacement.
> B) An additional event cancellation API.

This is just a quick reply, I'll hopefully be able to write something
more comprehensive later (at night 'UK' time, probably).

These are not two 'separate, primary changes': One of the features of
the 'other' data structure is that it enables efficient removal of
events which should no longer execute even when the event queue is
'fairly large' (and 'fairly large', compared to the existing
implementation, means something like '16 or more entries', possibly
even '8 or more entries' [I will do some comparison of that
'eventually']) with very little overhead (ideally, just an additional
unsigned member in the ev_entry' object, practically, at least for the
moment, an unsigned and a pointer) and this is crucial for using this
for 'timeouts' instead of using a multitude of 'special purpose'
this-that-and-something-else timeout handling code distributed accross
536 differen files with various unpleasant properties (such the time
needed checking for I/O timeouts is proportional to the
highest-numbered file descriptor currently in use and that these
timeouts are, judgeing from a quick glance, 'detected' by regularly
scheduled polling cycles). That's what I'm interested in at the moment
because I am using this for 'connect timeouts' (in a 'partner demo
installation' production setting meanwhile) and wouldn't mind moving
towards a unified timer subsystem for the squid 3.3 I'll have to
maintain step-by-step in future[*].

The 'event cancellation API' just exposes this particular feature.

No programming-related content below the page break.

[*] Don't assume that everyone you don't yet know must be more-or-less
a student warily trying his first 'real-world' programming steps. If I
have to deal with this for long enough, I will make this do what I
want it to do, exactly in the same way I also did this for all kinds
of other 'open source programs' almost capable of doing the job I need
to get done. For as long as these two versions haven't drifted apart
for too much, I'm willing to share my changes insofar I consider them
sufficiently 'generally useful', since this seems the right thing to
do given that (quoting my boss) "we just got a major feature for free"
(That would be the policing of 'HTTP-over-SSL' traffic. Thank you very
much). But I'm not in the position that I have more time on my hands
than I would know how to get rid of and this means that I'm first and
foremost interested in 'practical' (meaning "non 'rewrite-the-world'
style") modifications solving problems I happen to have.
Received on Thu Jan 31 2013 - 14:21:47 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 31 2013 - 12:00:08 MST