Subject | RE: [IB-Architect] Re: Events Improvement |
---|---|
Author | Jim Starkey |
Post date | 2001-05-09T13:56:40Z |
At 12:48 PM 5/9/01 +0400, Dmitry Yemanov wrote:
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
>Dimitry, another potential problem occurred to me. Events, of course,
>Thanks for your explanation. I hadn't enough time to learn it from the
>source code and understand in depth.
>
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