>From: "Dmitry Yemanov" <dimitr@...>
>To: <firebird-devel@...>
>Subject: RE: [Firebird-devel] Events Improvement
>X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
>Importance: Normal
>Sender: firebird-devel-admin@...
>X-BeenThere: firebird-devel@...
>X-Mailman-Version: 2.0.3
>Reply-To: firebird-devel@...
>X-Reply-To: <dimitr@...>
>List-Help: <mailto:firebird-devel-request@...?subject=help>
>List-Post: <mailto:firebird-devel@...>
>List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/firebird-devel>,
>
><mailto:firebird-devel-request@...?subject=subscribe>
>List-Id: <firebird-devel.lists.sourceforge.net>
>List-Unsubscribe:
><http://lists.sourceforge.net/lists/listinfo/firebird-devel>,
>
><mailto:firebird-devel-request@...?subject=unsubscribe>
>List-Archive: <http://lists.sourceforge.net/archives//firebird-devel/>
>Date: Wed, 2 May 2001 21:01:19 +0400
>
>Hi,
>
>I have practically finished (at least I think so) the work with the events
>enhancement (* and ? wildcards support was added). Unfortunately, I had only
>about 2-3 hours per week to work on it, so this plan was achieved later than
>I expected. I could commit the source files (as well as win32 binaries)
>right now, but I would prefer to get some feedback before making this step.
>You can find the brief explanation of the changes I made and questions I
>need to have answered below.
>
>IMPLEMENTATION
>
>Files touched: event_proto.h, event.h, event.c, utl.c, dfw.e, why.c (all in
>/jrd)
>
>The specification and implementation of event.c/find_event have been
>changed. Now it can work as before (exact match) to prevent an event to be
>registered twice and can also match using the wildcards (the simplified and
>optimized version of evl_like.c/matchesname is used) to provide the new
>behaviour. It also supports an iteration through all registered events that
>match the posted one.
>
>Then, I have slightly modified the algorithm of the satisfying requests
>delivery - now it is splitted into two stages. The first of them links the
>names of the actually posted events to the event masks that the client
>request is interesting in, and prepare those requests for delivery. The
>second stage delivers requests to appropriate clients and deletes completed
>requests from the system queue.
>
>And finally the last but not least, EPB (event parameter buffer) has been
>extended to let clients know real event names and counts (number of times
>each event was fired in the context of commited transaction). This extended
>EPB is used only when it is passed from the server to either client's event
>AST routine or isc_wait_for_event. All event APIs have been modified to
>ignore extended part of EPB in their input, so extended EPB looks to be 100%
>compatible with the original one and all existing applications should live
>as they did before.
>
>The only significant problem was that the server cannot pass extended EPB
>(which is larger than the original one) with its real length to the event
>AST, because almost all applications copy the updated buffer to the result
>buffer allocated before with isc_event_block and passed as the first
>parameter, e.g:
>
>isc_callback ast_routine(
> ARG(char ISC_FAR *, result),
> ARG(short, length),
> ARG(char ISC_FAR *, updated))
>ARGLIST(char *result)
>ARGLIST(char *updated)
>ARGLIST(short length)
>{
> while (length--)
> *result++ = *updated++;
> return 0;
>}
>
>that will definitely cause AVs and other memory faults. I have done the
>following trick to solve this problem - the server passes extended EPB to
>the internal AST stub (implemented in gds32), which in turns calls the real
>client's AST, but passes the second argument (length of EPB) decremented by
>the size of the extended part of EPB. So all old-style apps should work
>without a problem and all new ones can additionally check which actual
>events caused the AST to be called.
>
>But, AFAIK, the format of EPB has never been documented, so it would be
>better to have an additional API routine for getting extended event stuff
>than dealing directly with EPB. But this is a step that must not be done by
>a single developer, I think.
>
>TESTING
>
>I have built Firebird on my Win2k box and tried to run a few applications:
>- api16/api12 couple from /examples/api (via API)
>- specially written program that can wait for any given events (via IBX)
>- Jason's IB_WISQL that can do exactly the same (via IBO)
>- two real-world software systems (for compatibility testing) (both written
>with IBX)
>
>Results: all programs work pretty fine, but one of my real-world
>applications (not the server) crashes with AV when exiting. I have proven
>that it is definitely caused by my changes to EPB, although this routine
>seems to not work with EPB at all. The experiments show that the problem is
>somewhere within Y-valve - the exception is thrown from isc_cancel_events
>during the execution of the following code (located in why.c):
>
>if (CALL (PROC_CANCEL_EVENTS, database->implementation)(
> status,
> &database->handle,
> id))
> return error (status, local);
>
>The mistery is that I cannot find the reason. I only know that CALL macro
>returns valid pointer, all arguments look valid too, but the exception
>appears before jrd.c/gds_cancel_events starts working. I'm not a Y-valve
>guru yet, so I have stopped digging deeper. Yep, this problem is the only
>one and maybe nobody gets the same result, but I would prefer to make it
>crystal clear (at least for me).
>
>SUMMARY (THOUGHTS, QUESTIONS, WISHES)
>
>- if we vote for the new API routine, then we must make a decision regarding
>its name, arguments etc.
>- I would like this stuff to be tried to build on other platforms than Win32
>as soon as possible
>- if there are people who have real applications that use events and who
>could test their software with the modified engine, please do it
>- I believe TCS has tests for the event mechanism, so it must be also done
>without a doubt; I could do it by myself, but in this case I need some help
>to get TCS running on Win32
>- which macro should I use to isolate a piece of my code to the client
>library only? I used SUPERCLIENT, but AFAIK it won't work in Classic build
>- if we include these changes into Firebird 1.0, then we should have
>appropriate technical information (documentation, how-to's), provide new
>examples, etc. and ship all this stuff with the product
>- this functionality should be supported by IBO, IBX, FreeIB+, etc.
>- and, BTW, are there any thougths about my problem with isc_cancel_events?
>
>Sigh. There're a lot of things to think about, IMHO. So I'm waiting for your
>opinion...
>
>Cheers,
>Dmitry
>
>P.S. Source files are zipped and attached to this message. You can diff them
>against the latest sources from the tree to find the changes I made.

I've removed the source files to avoid annoying yahoogroups. If you
want them, send me mail.

Ann