Browse Prior Art Database

Event-Raising Mechanism for Networking Architecture Disclosure Number: IPCOM000117285D
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 106K

Publishing Venue


Related People

Adams, PS: AUTHOR [+3]


The Lakes Architecture raises events to applications. This is done by means of a "callback function" or "event handler" - a function in the application that is called by Lakes.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Event-Raising Mechanism for Networking Architecture

      The Lakes Architecture raises events to applications.  This is
done by means of a "callback function" or "event handler" - a
function in the application that is called by Lakes.

      These events have to be delivered in order and, where possible,
in a discrete manner i.e., without reentering the event handler with
a new event while the previous event is still being processed.

      The procedure described here achieves this even when an
application makes calls to Lakes within its event handler which will
not complete until further events have been processed.

      When an application registers with Lakes a thread is created on
its process.  This thread is the "doer" thread.  It has an associated
queue, to which events are posted.  The thread waits on this queue
and when an event arrives on the queue the thread calls the event
handler specified.

      This provides a serialized, discrete sequence of events raised
to the application.  The basic form the "doer" thread is defined by
the following pseudo - code:
  Basic doer thread =================
  void doer(void)
  bool32  os2_lakes_is_great = TRUE;
  event_data ev_data;
  while( os2_lakes_is_great )
  /***** Read the queue for a new event *****/
       WAIT \ REMOVE
  if(ev_data->type = = API_KILL_EVENT)
  /***** Kill event received - time to end this thread *****/
  /***** Process the event read from the queue *****/
  pre_process( ev_data );
  call_event_handler( ev_data );
  post_process( ev_data );
  /***** Doer thread quits *****/

      This is a standard event-raising mechanism on an operating
system which provides threads and queues, like OS/2*.

      This is not, however a complete solution.  If in the processing
of the event, the application issues a call which requires the
processing of another event a deadlock situation arises.

      To avoid deadlock, a second "safety" thread is created.  This
thread spends most of its time waiting on a semaphore.  When the doer
thread is about to call the event handler for an event, it starts a
timer function with a determined timeout value.  When the doer thread
returns from the event handler, it cancels the timer function.

      The timer function periodically clears the semaphore on which
the safety thread is waiting.  If the timeout period is exceeded
during the processing which occurs in the event handler the semaphore
will be cleared and the safety thread will come in to action.

      The safety thread checks to see if the doer thread is blocked
within Lakes.  If it is, then the safety thread remembers on which
internal Lakes semaphore the doer thread was waiting, and goes back
to waiting on its semaphore.  If the timeout period is exceeded for a
second time, the safety thread checks to see...