Leaderboard

I also seem to remember people saying that even though the lvproj file is ostensibly XML, merging it sometimes causes later loads to fail (maybe because of non-standard XML or binary elements in it), but I don't remember having practical experience with merging project files. In any case, if you have conflicts, they will have to be resolved (which in LV, probably means using the LVmerge EXE). Additional relevant points: Viewpoint recently released a TSVN toolkit which integrates straight into the project tree and is supposed to be very good and free. I haven't tested it myself because my TSVN version is too old and can't support it. There's a long series of detailed posts about working with SCC in LV, including SVN. It's probably worth reading at least the relevant parts. You can see the list here - https://decibel.ni.com/content/groups/atlanta/blog/2013/11/04/some-basic-git-info

I just rename them and let the SCC record the old class as deleted and the new one created.

I am thinking of expanding on this for a CLA Summit presentation. But before I invest a lot of time, I am wondering how many others think a tool like this would be useful. If you are interested, please reply or 'like' this post so I have an idea of the level of interest in this subject. thanks, -John

Not explicitly true -- for Queues, an enqueuer and a dequeuer are both accessing the same Queue object, whereas with Events, the enqueuer and dequeuer are interfacing with two separate objects -- the event publisher and the event registration/subscription. Any number of writers may write to a Queue, and you may have any number of readers as well; stated another way, contrary to popular belief, you may have multiple asynchronous dequeuers pulling out of the same queue. Events have a bit different semantic than Queues in LabVIEW -- there must be one and only one Handler bound to an Event Registration at any one time, yet there may be [0,N] Registrations per publisher. With this extra level of indirection, I don't know if we can even properly classify Events as being something-to-something, but rather (N publishers)-to-(M registrations)-to-(0 or 1 handlers bound to a registration at a time). Breaking it down: Queues are many-to-many, one-to-many, one-to-one, or many-to-one, depending on what makes sense for your application domain. Events support the same configurations, though with one additional level of indirection (which enables a host of additional design patterns), and the caveat that there may never be multiple readers (Event Handler Structures) simultaneously bound to one Event Registration. This caveat is the one I would like to see lifted, that Events might act more like Queues, in order to better support concurrent processing. Actually the other way around -- Queues have the advantage in LabVIEW for the time-being for the Piranha Brigade pattern, because Event Registrations do not yet allow multiple handlers to be concurrently bound to a single registration. The run time behavior is literally undefined -- utterly random results in the total number of events handled, at least as of LV2012.

Glad you found the source of the problem! Just to dive in and explore further to this statement above -- it's perfectly acceptable to register inside the loop prior to binding the registration to the Event Handler Structure -- though perhaps not typical. I'm guessing that the memory leak you found was due to the registration not being shifted in a Shift Register inside the loop code. This would cause a memory leak, since each iteration a new Event Registration Queue is formed. Though, if it's shifted, only one Event Registration is created, and then modified each subsequent iteration. Check out the snippet below, which simulates the difference between shifting and not shifting an event registration. The two Boolean controls -- Leak? and Handle Event? -- allow you to run the example in four modes: Handle Event == TRUE and Leak == FALSE - Though it remains atypical to re-register each iteration, this is the only of the four combinations that does not produce a memory leak. Handle Event == TRUE and Leak == TRUE - This is an interesting scenario that causes a leak of 100kb/iteration, even though the data is consumed (handled). This indicates that Event Registrations, like Queues, maintain a high-water mark as an optimization technique. (Thoric, I'm guessing this unintentional scenario was the bug in your code) Handle Event == FALSE and Leak == FALSE - This scenario might be used to pre-load a work queue, which would then later be bound to a single handler. This technique is useful if the computation-to-memory ratio is high, and time needed to calculate the work to be done is relative quick compared to the amount of time needed to do the work. (I wish that LabVIEW's Event Registration binding to an Event Handler had the same semantics as a Queue, with 1:N capabilities. Then, we could dynamically launch a pool of workers bound to the same work queue, and have the Piranha Brigade munch away at the work in concurrently and asynchronous from each other) Handle Event == FALSE and Leak == TRUE - This scenario is useless and almost certainly a bug, unless the Shift Register was replaced by an Auto-Indexing output, to which the array of registrations were later each bound to handlers. (Though even with the output array of registrations, this technique is not quite as desirable as the Piranha Brigade above, especially when the amount of time to perform each job is variable.)