Reusable Server Kernel

Problem 34 (Major): Line Driver behaviour during data send

=============== 2000-02-04 13:05:53 (-05.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
I forgot to say that the fix is available in
/rsk/rskfix.vmarc, available on this web server.
=============== 2000-02-04 13:04:01 (-05.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
I found that the line driver was sending the "client lost"
message to the instance but that the instance was blocked
in ssClientDataPut because of the pacing semaphore.  The 
line driver needs to flush the client output queue as part
of its process of initiating teardown of the connection to
the client.  Such flushing will cause the instance to wake
up from the SemWait.
Be advised also that a tight loop on ssClientDataPut is
ill-advised.  You need to be checking the line driver
queue every once in a while to see if there is a message
from the line driver telling you that the client has gone
south.  QueueReceiveImmed could be used for this purpose.
=============== 1999-12-27 18:26:27 (-05.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
What happens inside the RSK when a client (in this case connected
to the TCP line driver) "goes away" while an RSK application
is sending the client data? The data is being sent in a (tight)
(ssClientDataPut, QueueSend) loop. From tracing inside the 
application, it appears the control is not returned from whichever
QueueSend is in progress when the client breaks the connection.
Is there any way the line driver could tell the application
that this situation has occured, in much the same way the
line driver notifies the application of a btroken connection
when QueueReceiveBlock is called?
TIA