Chip
Walt Akers said:
Hey:
I've been thinking about how we can effectively detect when a message
that generates a multi-part response has finished delivering all of
its output, and I've come up with the following idea...
Foundation:
1) When a message is transmitted a cdevTranObj (transaction
object) is created that contains the callback object that
is associated with the request.
2) The callback object will be maintained in the transaction
object and called everytime a response is received.
3) The service keeps track of the transaction object throughout
its lifetime and deletes it when it is nolonger needed...
4) When the transaction is deleted, it will (if a flag is set)
delete its embedded cdevCallback object.
Therefore, when the transaction is deleted it could call the
cdevCallback object with a code in the status word indicating
the transaction is completed... i.e. CDEV_END_OF_TRANSACTION.
When the callback receives this message it would also be able to
delete the object stored in the "void * userarg" pointer if desired
(a capability that we do not currently have)...
An alternative would be to modify the destructor of the cdevCallback
object to call the callback when the cdevCallback object is deleted
with a status of CDEV_CALLBACK_DELETED... this would afford the
developer the opportunity to delete the "void * userarg" pointer and
clean up any memory that was setup to handle a multipart response...
However, this would not definitively mark the end of a multi-part
transaction - only the destruction of a cdevCallback object.
Ideas?
Walt
=============================================================
Walt Akers Voice: (757)269-7669 E-Mail: akers@cebaf.gov
Thomas Jefferson National Accelerator Facility
12000 Jefferson Avenue, MS 16A
Newport News, Va 23606
=============================================================
My response:
This could work for multi-part transactions, but is too much overhead
for single shot cmd/response.
Consider the flow as seen by the user:
Single-shot:
create user object
create callback object (temporary) pointing to user object
initiate transaction via device or request objects, which makes
a copy of the callback object
delete the callback object (temporary)
receive callback, delete any user objects no longer needed
Multi-shot:
same as above, except the callback status argument indicates
wether this is the final callback for this transaction. That is,
if it is NOT, we introduce a NEW status meaning "partial/ongoing".
when user gets the FINAL callback, he knows to delete his objects
I prefer this to transfering the "ownership" of the user object to the
callback object or the transaction. User is responsible for not deleting his
object until he cancels the transaction.
The difficulty is that we do not have a general way to cancel transactions,
because transactions are not visible objects, but rather implementation objects.
I am not ready to make them visible until someone has a clear need for it,
because once we make them visible, we can't change their implementation,
or rather their interface.
Chip