>
> All,
> I have a couple of questions about cdevRequestObject and how CDEV works.
>
> 1. From tracing the code it seems that when I send a message to a device
> through a device pointer, the code at a lower level creates a specific
> cdevRequestObject to handle the message. I think these objects are
> cached and are used for subsequent matching messages.
> If true, when I cdevRequestObject::attachPtr, I'm getting the cached
> cdevRequestObject object or creating a new one. Is this true?
> Does each device have a set of cdevRequestObject objects?
> If all this is true there is no penalty (extra objects?) for using the
> cdevRequestObject interface over the cdevDevice interface since the
> cdevDevice interface is built upon the cdevRequestObject?
Thats right... The cdevRequestObject AND the cdevDevice's are cached
and you can never create more than one of the same thing... (in the
same cdevSystem that is - but, since we are only using one cdevSystem
you are still okay).
>
> 2. In the example in the tutorial on page 33, it is shown how to alter
> the context of a cdevRequestObject for a "get bdl" message. I'm wondering
> why all the examples show restoring the old context. If cdevRequestObjects
> hang around and when I change the context of a single cdevRequestObject
> no other cdevRequestObjects are affected, wouldn't I only restore the old
> context if I was doing a unique, one-off command?
Well, how do you know that another part of your program isn't doing
some weird stuff to the context? Or maybe another piece of the code
is latering the context at the cdevDevice level? If you are sure that
none of this is going on behind your back, then you can dismiss
restoring the old context.
> If I set up a monitor using ca service and I just want the value, don't
> I change the context and leave it even after the message is sent?
> Can I tweak the context after the initial message is sent - in the callback?
> If I send one "monitor on X" message (a one off command) should I
> "detach" this object to save resources? I know the manual says I should
> not be calling detach.
Once the message has been sent, the context for the request is set
in stone (at least thats our idea of a perfect world). After sending
you should be able to change the context with impunity.
> 3. I've been trying to set the context for a ca service monitor to just
> get the value(VAL). No matter what I do in the context I get about 10 items
> in the cdevData object when I view it with asciiDump in the callback.
> What should I be setting the context to for this monitor. Is the
> success of setting the context tied to the specific record type being
> monitored (I think this is false)? The record I'm attaching to is one
> of our own and it might have bugs.
We were having that problem, too, but we came up with an answer (one
that I can't recall exactly). Try setting the context values for the
other tags to 0 (I know thats cumbersome, but try it anyway and see if
it works).
> Finally.
>
> 4. When I send a "monitor on" to a device. Is the cdevRequestObject
> passed in the callback the one that I used to send the initial monitor
> on message to the device (even if I went through cdevDevice I guess)?
> How does one use this object in the callback? I guess I'm asking
> why it is included in the callback arguments. If I detach-ed
> the cdevRequetObject would I break the callback?
If you detach a cdevRequestObject that is actively being used to
do stuff... it won't go away (or at least it shouldn't). The
cdevRequestObject is included with the callback so you can find out
what the device name or message is that was associated with the
request.
> Thanks for your help. I'm enjoying my CDEV experience. I'm just trying
> to understand how the pieces fit together.
>
> Kim Gillies
> Gemini Telescopes Project
Best of luck,
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
=============================================================