Caitlin, what if we remove the section on model implications? We did the survey of applications written on uDAPL and none of them are using an EVD for all...
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the dat-discussions group. File :...
dat-discussions@yahoo...
Apr 1, 2003 9:51 pm
2070
This file contains the following additions and changes with respect to the previous 3/26/03 posting: 1. changes for 2 level error proposal - errata #2, 2....
... We spent a fair amount of time discussing the need for CR and connection events to be delivered in sequence with DTO/RMR completions. In particular, the...
Caitlin, I do not disagree on usefulness of single EVD capable of supporting all event stream. I just do not see this as a requirement for all Providers. ...
I have added that dat_registry_list_providers is thread safe. Any objection if dat_strerror also be thread safe. I see no need to force Consumer threads to...
Sorry, I missed this discussion when I updated the spec for errate #62. The new change I have just made removed: When a Provider Library is loaded it must...
This posting proposes a method to allow the DAT registry to know which version of dat.h a Consumer or Provider was compiled with. It also specifies how that...
I realized that the discussion of thread-safety mode really needed to be integrated with this. That also led to a cleaner interface for the enhanced version of...
Attached is an update to my previous Static Registry discussion doc. The updates are: * Most Static Registry ISSUEs resolved. * Changed "application" to...
I had reviewed all the places where UpCall is used in the uDAPL spec. There are really only 2 places where it is used. 1. In the Event Management section there...
To define the semantic and impact of a thread dying in a thread-safe DAT routine is vey complicated issue. We will not be able to resolve it in 2 weeks...
We have the following errata description: Define behavior for UpCalls that are in progress as well as UpCalls registered for EVD when ia_close is called....
What about Async EVD descruction at ia_close? I suggest to add the following text for ia_close: If async EVD was created as part of the of ia_open then...
What happens with rmr_free when rmr is not unbound? I suggest to add the following text for rmr_free: RMR_free is allowed on either bound or unbound RMR. If...
... UpCalls registered for EVD when ia_close is called. Analogous ... similar text for evd_free. ... If an upcall has been initiated by the kDAPL EVD, then it ...
... I'd suggest adding: A Provider should always place an entry for a non-threadsafe version in the static registry to match each threadsafe version, even if...
We do not clearly specify what happens when lmr or rmr is freed when it is used in some posted operation. For the RMR we have the following text in lmr_free: ...
... after ... to ... an ... The Consumer MUST NOT assume that the EVD that invoked it still exists. It may be deleted during the duration of the upcall. But on...
I suggest to add the following paragraph to 61. API conventions: API convention in DAT are as follows: 1. All OUT parameters are passed as pointers and hence...
... This should probably be named "dat_registry_set_threadsafe", so that it is clear that it resides in the registry. All other registry resident routines are...
... RMRs grant permission to access local memory. So anytime that permission is revoked, any future reference to the RMR must fail to grant that permission....
... A statically linked Provider must be initialized by the application, rather than the registry. It should call dat_registry_add_provider() just as it would...
... The existence of an IA Name must be known statically (or at least it must be entered into the Static registry, but that could be done by a plug-n-play...
I would like to quick poll in this. Does anybody has a problem with it? I Propose that we close this errata item for DAPL-1.1 and address it immideately after...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
