Menu
▾
▴
epics-pvdata-core — CLOSED: Archived discussions of core EPICS V4 core modules team.
This list is closed, nobody may subscribe to it.
| 2011 |
Jan
|
Feb
|
Mar
(48) |
Apr
(18) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Marty K. <mrk...@co...> - 2011-06-07 16:59:39
|
I also made the include/pv changes to pvServiceCPP. BUT pvServiceCPP has not been updated for shared_pointers in pvAccess. Marty On 06/07/2011 08:39 AM, Marty Kraimer wrote: > I have made the changes to all of pvDataCPP, pvAccessCPP, and pvIOCCP. > I tested v3Channel and exampleChannel via pvIOCCP and javaIOC. > > I committed and pushed the changes. > > > Guobao, > > Have You made any changes to pvServiceCPP? > > If so please commit and changes and I will also update pvServiceCPP so > that it gets/puts include files to include/pv > > Marty > > Marty > > On 06/06/2011 02:51 PM, Marty Kraimer wrote: >> Unless I hear otherwise I will implement the changes tomorrow Morning. >> >> Marty >> >> On 06/03/2011 03:10 PM, Marty Kraimer wrote: >>> In order to help prevent include file name clashes it was agreed that >>> all<top>/include files the appear in pvDataCPP,pvAccessCPP, and >>> pvIOCCP must be included via >>> >>> #include<pv/xxx.h> >>> >>> I have a perl script ready that automates the changes to implement this. >>> >>> But the changes could result in a major mercurial merge problem for >>> anyone who has unpushed changes in any of the three projects. >>> To save grief it will best to have all changes committed and pushed >>> while I make the changes. >>> >>> I suggest that I make the changes next Tuesday morning. >>> It should only take a couple of hours to make the changes and run tests. >>> >>> Does anyone have an objection to this? >>> >>> Marty >>> >>> ------------------------------------------------------------------------------ >>> Simplify data backup and recovery for your virtual environment with vRanger. >>> Installation's a snap, and flexible recovery options mean your data is safe, >>> secure and there when you need it. Discover what all the cheering's about. >>> Get your free trial download today. >>> http://p.sf.net/sfu/quest-dev2dev2 >>> _______________________________________________ >>> Epics-pvdata-core mailing list >>> Epi...@li... >>> https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core >>> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with vRanger. >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Discover what all the cheering's about. >> Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> Epics-pvdata-core mailing list >> Epi...@li... >> https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core >> > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Epics-pvdata-core mailing list > Epi...@li... > https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core > |
|
From: Marty K. <mrk...@co...> - 2011-06-07 12:39:34
|
I have made the changes to all of pvDataCPP, pvAccessCPP, and pvIOCCP. I tested v3Channel and exampleChannel via pvIOCCP and javaIOC. I committed and pushed the changes. Guobao, Have You made any changes to pvServiceCPP? If so please commit and changes and I will also update pvServiceCPP so that it gets/puts include files to include/pv Marty Marty On 06/06/2011 02:51 PM, Marty Kraimer wrote: > Unless I hear otherwise I will implement the changes tomorrow Morning. > > Marty > > On 06/03/2011 03:10 PM, Marty Kraimer wrote: >> In order to help prevent include file name clashes it was agreed that >> all<top>/include files the appear in pvDataCPP,pvAccessCPP, and >> pvIOCCP must be included via >> >> #include<pv/xxx.h> >> >> I have a perl script ready that automates the changes to implement this. >> >> But the changes could result in a major mercurial merge problem for >> anyone who has unpushed changes in any of the three projects. >> To save grief it will best to have all changes committed and pushed >> while I make the changes. >> >> I suggest that I make the changes next Tuesday morning. >> It should only take a couple of hours to make the changes and run tests. >> >> Does anyone have an objection to this? >> >> Marty >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with vRanger. >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Discover what all the cheering's about. >> Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> Epics-pvdata-core mailing list >> Epi...@li... >> https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core >> > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Epics-pvdata-core mailing list > Epi...@li... > https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core > |
|
From: Marty K. <mrk...@co...> - 2011-06-06 18:51:18
|
Unless I hear otherwise I will implement the changes tomorrow Morning. Marty On 06/03/2011 03:10 PM, Marty Kraimer wrote: > In order to help prevent include file name clashes it was agreed that > all<top>/include files the appear in pvDataCPP,pvAccessCPP, and > pvIOCCP must be included via > > #include<pv/xxx.h> > > I have a perl script ready that automates the changes to implement this. > > But the changes could result in a major mercurial merge problem for > anyone who has unpushed changes in any of the three projects. > To save grief it will best to have all changes committed and pushed > while I make the changes. > > I suggest that I make the changes next Tuesday morning. > It should only take a couple of hours to make the changes and run tests. > > Does anyone have an objection to this? > > Marty > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Epics-pvdata-core mailing list > Epi...@li... > https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core > |
|
From: Marty K. <mrk...@co...> - 2011-06-06 12:44:14
|
On 06/05/2011 04:33 AM, Matej Sekoranja wrote: > > It never returns from > > channelGetRequester->channelGetConnect( > > Status::OK, > > getPtrSelf(), > > pvTop, > > bitSet); > > > You call getPtrSelf(), i.e. shared_from_this(), in constructor, when > nobody owns shared_pointer to the instance being constructed. > This throws an exception (so actually channelGetConnect gets never > called). > > This is also reported: > > $ ./bin/darwin-x86/pvget exampleChannel > [exampleChannel] failed to create channel get: Status [type=FATAL, > message=tr1::bad_weak_ptr] > > You must all channelGetConnect() later. > > Matej Thanks, I made changes so that most initialization is done in an init method instead of a constructor.. It now works. I also found the problem with the crash when I created and immediately destroyed a channel. I was calling channelCreated twice!! exampleChannel now works but it still needs some more work. Marty |
|
From: Matej S. <mat...@co...> - 2011-06-05 08:33:36
|
> It never returns from > channelGetRequester->channelGetConnect( > Status::OK, > getPtrSelf(), > pvTop, > bitSet); You call getPtrSelf(), i.e. shared_from_this(), in constructor, when nobody owns shared_pointer to the instance being constructed. This throws an exception (so actually channelGetConnect gets never called). This is also reported: $ ./bin/darwin-x86/pvget exampleChannel [exampleChannel] failed to create channel get: Status [type=FATAL, message=tr1::bad_weak_ptr] You must all channelGetConnect() later. Matej |
|
From: Marty K. <mrk...@co...> - 2011-06-03 19:10:57
|
In order to help prevent include file name clashes it was agreed that all <top>/include files the appear in pvDataCPP,pvAccessCPP, and pvIOCCP must be included via #include <pv/xxx.h> I have a perl script ready that automates the changes to implement this. But the changes could result in a major mercurial merge problem for anyone who has unpushed changes in any of the three projects. To save grief it will best to have all changes committed and pushed while I make the changes. I suggest that I make the changes next Tuesday morning. It should only take a couple of hours to make the changes and run tests. Does anyone have an objection to this? Marty |
|
From: Marty K. <mrk...@co...> - 2011-06-03 19:02:43
|
In May I visited BNL to discuss my priorities now the v3Channel which
implements a version of Channel that provides pvAccess to V3 records.
My priority now is to help Goubao start implementing services that run
in pvIOCCP.
Since it will take a lot of effort to implement support for V4 records
that includes support and record processing it means that a service must
do more work than services in javaIOC. The services in javaIOC are
implemented via support attached to a field of a V4 record which has
fields related to the service.
A base class for Channel now exists that implements some of the common
things that must be done to implement Channel.
v3Channel was modified to use this base class. I have tested and
committed what has been done so far.
There is still more work to do on this base class before it is ready for
use.
BUT there are still problems and I need Matej to look and see if he can
help.
I have created an exampleChannel that extends PVServiceBase.
When /home/mrk/hg/pvIOCCPP/iocBoot/testV3Channel is started the
exampleChannel is stated that supports a single channel named
exampleChannel.
To see what is wrong do the following:
start the IOC via
valgrind ../../bin/linux-x86/testV3Channel st.cmd
valgrind will show what is wrong
On the javaIOC swtshell ask for get
1) connect to exampleChannel.
It does connect but then immediately disconnect
valgrind will show what is wrong.
2) again start the IOC (not necessary to run under valgrid)
connect get to exampleChannel
click createGet
Note the message on the IOC console.
They are coming from pvIOCCPP/pvIocApp/exampleService/exampleChannelGet.cpp
It never returns from
channelGetRequester->channelGetConnect(
Status::OK,
getPtrSelf(),
pvTop,
bitSet);
Any ideas?
Marty
|
|
From: Michael D. <mda...@bn...> - 2011-04-21 02:55:08
|
Hello Matej, > What I want you to do is to check > pvAccessCPP-md/pvAccessApp/client/pvAccess.h if its OK for you. It looks good. Only one minor point. When passing shared_ptr as arguments it is better to use const references. This prevents the function being called from reset()ing the pointer (unless this is desired). eg. void func(const MyType::pointer&); > I've committed my changes to pvAccessCPP-md. > I haven't yet done pointer to shared_pointer replaces. > It would not compile also, since some changes are needed in pvData (i.e. > pointer typedefs). If you want you can push the renamed typedefs to pvData-md when you are ready. Thanks, Michael |
|
From: Marty K. <mrk...@co...> - 2011-04-19 09:24:38
|
On 04/18/2011 05:48 PM, Matej Sekoranja wrote: > I've committed my changes to pvAccessCPP-md. > I haven't yet done pointer to shared_pointer replaces. > It would not compile also, since some changes are needed in pvData > (i.e. pointer typedefs). > > What I want you to do is to check > pvAccessCPP-md/pvAccessApp/client/pvAccess.h if its OK for you. > > I think you are asking Michael but just in case it is OK with me. Also I made one change to pvDataCPP (In PVField extending Requester was made virtual). I pushed this change. So if you need to make changes to PVDataCPP go ahead. I am working on /home/mrk/hg/pvIOCCPP/pvIocApp/database. I am waiting for your pvAccessCPP changes before looking further at memory leak problems in V3Channel. V3Channel appears to work except for the memory leaks. Doc for V3Channel appears in pvIOCCP/documentation. Marty |
|
From: Matej S. <mat...@co...> - 2011-04-18 21:48:59
|
I've committed my changes to pvAccessCPP-md. I haven't yet done pointer to shared_pointer replaces. It would not compile also, since some changes are needed in pvData (i.e. pointer typedefs). What I want you to do is to check pvAccessCPP-md/pvAccessApp/client/pvAccess.h if its OK for you. Matej |
|
From: Michael D. <mda...@bn...> - 2011-04-18 02:36:42
|
On 04/17/11 17:08, Matej Sekoranja wrote: > > In the interest of making a decision I would go with shared_pointer over > sharedPointer, but am open to something shorter (const_shared_pointer > will wear out my fingers). > > I'll wait until tomorrow before changing this. > > > I have one MAJOR commit to do. I've changed pvAccessCPP-md to heavily > used shared_ptr-s. > I've tried to commit but I have not permissions on pvAccessCPP-md. Can I > do this, Michael? Yes. I've fixed the permissions. > I would like to commit/push on -md not to break pvServiceCPP, pvIOCCPP, > After this we can agree on new pvAccess.h. > > Until now I've used "pointer" name. I can quickly do a file replace... > to shared_pointer (and co.). OK? Ok. > > Matej |
|
From: Matej S. <mat...@co...> - 2011-04-17 21:08:40
|
> > > In the interest of making a decision I would go with shared_pointer over > sharedPointer, but am open to something shorter (const_shared_pointer > will wear out my fingers). > > I'll wait until tomorrow before changing this. > I have one MAJOR commit to do. I've changed pvAccessCPP-md to heavily used shared_ptr-s. I've tried to commit but I have not permissions on pvAccessCPP-md. Can I do this, Michael? I would like to commit/push on -md not to break pvServiceCPP, pvIOCCPP, After this we can agree on new pvAccess.h. Until now I've used "pointer" name. I can quickly do a file replace... to shared_pointer (and co.). OK? Matej |
|
From: Marty K. <mrk...@co...> - 2011-04-15 18:40:46
|
I new method was added to PVDataCreate that allows a PVStructure to be created from a PVField array. The PVFields can be created with a null parent. PVStructure has a new constructor to support the new feature. It calls setParent recursively on each subfield. This is much more efficent that creating a PVStructure with no subfields and then appending new PVFields. PVField::message was changed to pass the message up the parent tree adding the field name at each level. Also only the top level field supports setRequester. These changes were made in both the C++ and Java versions of pvData. The java changes also required changes in the javaIOC and in integrationTests. |
|
From: Marty K. <mrk...@co...> - 2011-04-13 10:48:58
|
Matej, I am starting to look at memory leaks in V3Channel. Could I get you to look. There are problems with just starting an IOC and stopping it without any activity. ==3595== LEAK SUMMARY: ==3595== definitely lost: 120 bytes in 5 blocks ==3595== indirectly lost: 0 bytes in 0 blocks ==3595== possibly lost: 3,791 bytes in 62 blocks ==3595== still reachable: 600,859 bytes in 11,127 blocks ==3595== suppressed: 0 bytes in 0 blocks The first few reports are: Thread 1: ==3595== 14 bytes in 1 blocks are possibly lost in loss record 245 of 787 ==3595== at 0x4006241: operator new(unsigned int) (vg_replace_malloc.c:255) ==3595== by 0x56BAD05: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.14) ==3595== by 0x4105509: epics::pvAccess::SystemConfigurationImpl::getPropertyAsBoolean(std::string, bool) (basic_string.tcc:138) ==3595== by 0x411CAEC: epics::pvAccess::ServerContextImpl::loadConfiguration() (serverContext.cpp:86) ==3595== by 0x411D801: epics::pvAccess::ServerContextImpl::ServerContextImpl() (serverContext.cpp:43) ==3595== by 0x403CDA3: MyRun::MyRun() (startPVAccessServer.cpp:47) ==3595== by 0x403CE9D: startPVAccessServerCallFunc(iocshArgBuf const*) (startPVAccessServer.cpp:83) ==3595== by 0x42A76E8: iocshBody (iocsh.cpp:743) ==3595== by 0x804A90C: main (exampleMain.cpp:17) I ran valgrind via the statement: valgrind --log-file=temp --leak-check=full ../../bin/linux-x86/example st.cmd Then just immediately exit. Marty |
|
From: Marty K. <mrk...@co...> - 2011-04-07 19:11:14
|
On 04/06/2011 02:53 PM, Marty Kraimer wrote: > I pushed the latest version of pvIOCCP. > Monitor stop and disconnect now work properly. > > Still to do. > > 1) Special fields not handled proerly. For puts I will call dbPut and > let it handle all the problems. > 2) memory leaks. Track them down with valgrind. > 3) access security. Will probably wait to implement this. For now > realize that v3Channel completely sidesteps access security. > I looked and it appears to be fairly easy to implement access security > since it allows servers besides CAV3 to access it. > > > Modifying special and link fields now works. As a demo do the following: monitor counter01 so that you can see what happens. Two tests: attach put to counter01.SCAN It will appear as an enumerated structure. change the index to 0. The counter will stop. change the index to 8. the counter will count fast. Then attach put to counter01.INPA It will appears as a string. set the value to null. The counter will process but not count set to value back to counter01 NPP NMS. The counter will start counting again. Now for some documentation and then valgrind and then some more testing. Matej, Did you get a chance to look at the null pointers and reconnect? |
|
From: Marty K. <mrk...@co...> - 2011-04-06 18:53:35
|
I pushed the latest version of pvIOCCP. Monitor stop and disconnect now work properly. Still to do. 1) Special fields not handled proerly. For puts I will call dbPut and let it handle all the problems. 2) memory leaks. Track them down with valgrind. 3) access security. Will probably wait to implement this. For now realize that v3Channel completely sidesteps access security. I looked and it appears to be fairly easy to implement access security since it allows servers besides CAV3 to access it. |
|
From: Marty K. <mrk...@co...> - 2011-04-06 15:15:00
|
I have successfully created a monitor, started it, stopped it, destroyed it, and did this again!!! I had to use both epicsAtThreadExit and ca_attach_context to get it to work. Marty |
|
From: Marty K. <mrk...@co...> - 2011-04-06 09:41:51
|
On 04/05/2011 03:30 PM, Michael Davidsaver wrote: > On 4/5/2011 1:51 PM, Marty Kraimer wrote: >> On 04/05/2011 01:12 PM, Marty Kraimer wrote: >>>> >>>> 3) I want to call ca_context_destroy when the thread is being >>>> destroyed. How? >>>> > > epicsAtThreadExit() > > Registers a callback when the thread is terminated. > Thanks just what I needed. I was amazed when I found that I wrote the original version. I have no memory of doing it. |
|
From: Michael D. <mda...@bn...> - 2011-04-05 19:30:59
|
On 4/5/2011 1:51 PM, Marty Kraimer wrote: > On 04/05/2011 01:12 PM, Marty Kraimer wrote: >>> >>> 3) I want to call ca_context_destroy when the thread is being >>> destroyed. How? >>> epicsAtThreadExit() Registers a callback when the thread is terminated. |
|
From: Marty K. <mrk...@co...> - 2011-04-05 19:21:30
|
On 04/05/2011 02:05 PM, Matej Sekoranja wrote: > What about simply checking thread ID each time createChannel is called. > Then you can have a map<thread ID, ca_context> to get existing ca_context > ore create a new one (and put it on map). Of course, you cache it in > your own channelV3 impl. > You release contexts in destory() methods. Sure, you need ref. count > (shared_ptr). > > That is almost exactly what I have started!!! Thanks now I feel confident that it is a good way to go. Marty |
|
From: Matej S. <mat...@co...> - 2011-04-05 18:06:04
|
What about simply checking thread ID each time createChannel is called. Then you can have a map<thread ID, ca_context> to get existing ca_context ore create a new one (and put it on map). Of course, you cache it in your own channelV3 impl. You release contexts in destory() methods. Sure, you need ref. count (shared_ptr). Matej On Tue, Apr 5, 2011 at 7:51 PM, Marty Kraimer <mrk...@co...> wrote: > On 04/05/2011 01:12 PM, Marty Kraimer wrote: > > > 2) Is there some way for me to get called by this thread shortly after >> the thread is created? >> > > 3) I want to call ca_context_destroy when the thread is being destroyed. >> How? > > > Hmmm.... does epicsThread (or pvData Thread object) allows API to monitor > thread creation/destruction? > > > Not that I can see. > > I see a solution without requiring changes elsewhere. > > I already have a class CAV3Context. > I will make it a singleton. > It has a method start. I will and a method stop. > When a channel is created it will cal start and when destroyed stop. > It will keep a reference count. > When reference count reaches 0 it will call ca_context_destroy. > > Don't know what I was thinking. This will not work. > I will get called for many different pvAccess clients. Each has different > thread. > > Needs more thought. > > Marty > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Epics-pvdata-core mailing list > Epi...@li... > https://lists.sourceforge.net/lists/listinfo/epics-pvdata-core > > |
|
From: Marty K. <mrk...@co...> - 2011-04-05 17:52:08
|
On 04/05/2011 01:12 PM, Marty Kraimer wrote: > >> 2) Is there some way for me to get called by this thread shortly >> after the thread is created? >> >> >> 3) I want to call ca_context_destroy when the thread is being >> destroyed. How? >> >> >> Hmmm.... does epicsThread (or pvData Thread object) allows API to >> monitor thread creation/destruction? >> > > Not that I can see. > > I see a solution without requiring changes elsewhere. > > I already have a class CAV3Context. > I will make it a singleton. > It has a method start. I will and a method stop. > When a channel is created it will cal start and when destroyed stop. > It will keep a reference count. > When reference count reaches 0 it will call ca_context_destroy. > Don't know what I was thinking. This will not work. I will get called for many different pvAccess clients. Each has different thread. Needs more thought. Marty |
|
From: Marty K. <mrk...@co...> - 2011-04-05 17:12:46
|
On 04/05/2011 10:37 AM, Matej Sekoranja wrote: > > > Second problem: > > For monitors I have to go through CAV3 because db_post_event is in > dbEvent and it directly interfaces to CAV3. > > I have to call ca_context_create(ca_enable_preemptive_callback). > > This assumes that ALL calls to ca will be done by the same thread > that calls ca_context_create. > > > If I am not wrong you can also use other threads as long as you call > something called "attach". Yes but from what you say below there is no need. > > So three questions: > 1) Will all createChannelXXX calls be made by the same thread? > I think the answer is yes. > > > There are 2 threads per connection. You will receive all calls from > receive thread. > So, you can expect all calls related to XXX request from the same > thread that has called createChannelXXX. > Note that you can have several connections (but each channel lives > only in a context of one connection). > Good!!! > The only exception is destroy(). This can be called from other thread > (for now). That is OK. I think I can call ca_context_destroy from another thread. > 2) Is there some way for me to get called by this thread shortly > after the thread is created? > > > 3) I want to call ca_context_destroy when the thread is being > destroyed. How? > > > Hmmm.... does epicsThread (or pvData Thread object) allows API to > monitor thread creation/destruction? > Not that I can see. I see a solution without requiring changes elsewhere. I already have a class CAV3Context. I will make it a singleton. It has a method start. I will and a method stop. When a channel is created it will cal start and when destroyed stop. It will keep a reference count. When reference count reaches 0 it will call ca_context_destroy. Marty |
|
From: Matej S. <mat...@co...> - 2011-04-05 14:37:55
|
> > Matej, > > I need some help. > > Two problems: > > First problem: > I will have a look. Second problem: > > For monitors I have to go through CAV3 because db_post_event is in dbEvent > and it directly interfaces to CAV3. > > I have to call ca_context_create(ca_enable_preemptive_callback). > > This assumes that ALL calls to ca will be done by the same thread that > calls ca_context_create. > If I am not wrong you can also use other threads as long as you call something called "attach". So three questions: > 1) Will all createChannelXXX calls be made by the same thread? > I think the answer is yes. > There are 2 threads per connection. You will receive all calls from receive thread. So, you can expect all calls related to XXX request from the same thread that has called createChannelXXX. Note that you can have several connections (but each channel lives only in a context of one connection). The only exception is destroy(). This can be called from other thread (for now). > 2) Is there some way for me to get called by this thread shortly after the > thread is created? > 3) I want to call ca_context_destroy when the thread is being destroyed. > How? Hmmm.... does epicsThread (or pvData Thread object) allows API to monitor thread creation/destruction? Matej |
|
From: Marty K. <mrk...@co...> - 2011-04-05 13:45:01
|
Implementing the pvAccess Channel interface to V3 records is taking a
LOT longer than I expected.
Lots is now working but there are still problems.
I also fixed a couple of bugs in pvDataCPP and implemented monitorQueue.
I also had to replace "Structure *" to "StructureConstPtr" in pvAccess.
All the changes have been pushed.
Matej,
I need some help.
Two problems:
First problem:
When I run the example
mrk> pwd
/home/mrk/hg/pvIOCCPP/iocBoot/testV3Channel
mrk> ../../bin/linux-x86/testV3Channel st.cmd
And then start a JavaIOC to talk to it everything seems to work fine but
then when I start just one more get/put all the ones that have connected
already disconnect. They automatically reconnect.
On the JavaIOC the following message appears:
Apr 5, 2011 9:17:27 AM org.epics.ca.impl.remote.tcp.BlockingTCPTransport
processReadCached
SEVERE: Unexpected exception caught in thread processing requests.
java.lang.NullPointerException
at
org.epics.pvData.factory.BaseStructure.initializeFields(BaseStructure.java:47)
at org.epics.pvData.factory.BaseStructure.<init>(BaseStructure.java:34)
at
org.epics.ca.impl.remote.IntrospectionRegistry.deserializeStructureField(IntrospectionRegistry.java:328)
at
org.epics.ca.impl.remote.IntrospectionRegistry.deserialize(IntrospectionRegistry.java:299)
at
org.epics.ca.impl.remote.IntrospectionRegistry.deserialize(IntrospectionRegistry.java:278)
at
org.epics.ca.impl.remote.IntrospectionRegistry.deserialize(IntrospectionRegistry.java:151)
at
org.epics.ca.impl.remote.IntrospectionRegistry.deserializeStructureAndCreatePVStructure(IntrospectionRegistry.java:386)
at
org.epics.ca.client.impl.remote.ChannelGetRequestImpl.initResponse(ChannelGetRequestImpl.java:123)
at
org.epics.ca.client.impl.remote.BaseRequestImpl.response(BaseRequestImpl.java:153)
at
org.epics.ca.client.impl.remote.ChannelGetRequestImpl.response(ChannelGetRequestImpl.java:1)
at
org.epics.ca.client.impl.remote.handlers.DataResponseHandler.handleResponse(DataResponseHandler.java:49)
at
org.epics.ca.client.impl.remote.ClientResponseHandler.handleResponse(ClientResponseHandler.java:106)
at
org.epics.ca.impl.remote.tcp.BlockingTCPTransport.processReadCached(BlockingTCPTransport.java:521)
at
org.epics.ca.impl.remote.tcp.BlockingTCPTransport$2.run(BlockingTCPTransport.java:220)
at java.lang.Thread.run(Thread.java:636)
Just bring up about three put and three get controls:
In the put set record[process=true]
Then start attaching to different channels such as double01, string01, etc.
That should be enough to cause the problem.
Second problem:
For monitors I have to go through CAV3 because db_post_event is in
dbEvent and it directly interfaces to CAV3.
I have to call ca_context_create(ca_enable_preemptive_callback).
This assumes that ALL calls to ca will be done by the same thread that
calls ca_context_create.
So three questions:
1) Will all createChannelXXX calls be made by the same thread?
I think the answer is yes.
2) Is there some way for me to get called by this thread shortly after
the thread is created?
3) I want to call ca_context_destroy when the thread is being
destroyed. How?
Marty
|