Jim,

In IBO I have designed the event alerter component to use the AST merely to
set a flag that events are waiting to be queried. I noticed that it is safe
to delay the counts due to how the count blocks are built. You won't miss
any events because once you lock in it cumulates from there.

I also have an OnWakeUp mechanism that eventually results in setting an
event signaling a thread to come out of the rat hole if its been there
waiting for a signal. If nothing else is specifically setup the default
behavior is to tell Windows to churn up a WM_IDLEENTER message so that it
will kick the passive tasks processing (which events are hooked into if
Passive is set to true). Thus, they are handled on the IDLE CPU.

Then, when the thread gets the counts it is actually the main thread instead
of the AST thread. Wouldn't this effectively work around the problem? It
could be documented that this needs to be synchronized in such manner. Also,
it appears that Delphi uses its own memory manager so it probably doesn't
matter any way. But, I guess the required memory allocations could be
getting performed by the GDS32.DLL code instead of my client, right?

I'm trying to figure out what kind of changes I would need to make in my
event alerter component to accommodate these new enhancements properly. From
the looks of things I many not need to change much of anything.

All other event components written for Delphi (that I have examined) appear
void of any good wakeup mechanism and just do everything using the AST
thread, which I consider a "no-no". I suppose these components might have
problems with these new proposed features.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <IB-Architect@yahoogroups.com>; <IB-Architect@yahoogroups.com>
Sent: Wednesday, May 09, 2001 6:56 AM
Subject: RE: [IB-Architect] Re: Events Improvement


> At 12:48 PM 5/9/01 +0400, Dmitry Yemanov wrote:
> >
> >Thanks for your explanation. I hadn't enough time to learn it from the
> >source code and understand in depth.
> >
>
> Dimitry, another potential problem occurred to me. Events, of course,
> are delivered asynchronously; the synchronous call is just a layer
> on the asynchronous mechanism. There are two ways that the
> asynchronous part can be implemented on a client: threads and
> ASTs (asynchrous traps or signals).
>
> There are no problems with threads. There are potential big problems
> with ASTs. The problem with AST/signals is that on most operating
> systems there are severe limitations on what in the signal handler.
> Many OS service and even more library functions don't work and/or
> interfere with the base program. The most serious problem is that
> malloc is unreliable, corrupting the heap, double allocating blocks,
> and similar horrors. The original event handler was designed to
> eliminate the need to allocate memory at AST level, hence the requirement
> that the event parameter block received be exactly the same length as
> the one sent.
>
> The underlying problem is straightforward -- the data structures
> used by, say, the heap manager need to be interlocked, but the
> regular synchonization primitives are guaranteed to deadlock
> if interrupted while the heap is lock. The correct way to handle
> this problem under traditional Unix is to block ASTs in a critical
> region, but relatively few pieces of code do this. And with
> libraries based on zillions of globals (shame on Unix), things
> like errno, date handling, temp filename generation get unavoidable
> screwed up.
>
> I believe your change requires the AST routine to be able to
> receive an arbitrarily long event parameter block without calling
> gds_alloc, malloc, or any of their friends and relations.
>
> Perhaps all signaled event handler have been replaced by threads
> (and maybe professional wrestling is for real). Or maybe all
> Unix's (no, plural of Unix is not Multix) have fixed malloc
> to be AST-re-entrant. And maybe Borland has fixed gds_alloc
> to be AST-re-entrant. If not, you will need to find a work
> around.
>
>
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>