Jump to content

JackDunaway

Members
  • Content Count

    363
  • Joined

  • Last visited

  • Days Won

    38

JackDunaway last won the day on November 1 2016

JackDunaway had the most liked content!

Community Reputation

159

About JackDunaway

  • Rank
    Extremely Active

Profile Information

  • Gender
    Not Telling
  • Location
    Austin

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2006

Recent Profile Visitors

4,036 profile views
  1. Just now seeing this topic, and cross-referencing against some of my own uptime monitoring. Something happened this day which made lavag.org respond faster, but probably affected labviewwiki in the process:
  2. Are all your variables bound to your prepared statement? For example, rather than SELECT foo FROM table1 WHERE col='bar' the statement SELECT foo FROM table1 WHERE col=@value_to_match -- then later binding 'bar' to @value_to_match is going to be more performant (over multiple queries, especially), more precise (for floating-point numbers), and more secure (against SQL Injection Attack, assuming that the original `bar` was inserted at run-time using the likes of the labview `Format to String` function or C `snprintf()`).
  3. Unless something has changed, both the Embedded Web Server and Application Web Server are AppWeb by EmbedThis. That web server in and of itself seems pretty capable and pretty sweet, but the wrapper that LabVIEW puts around it strips and sanitizes virtually all of the configuration file options: https://embedthis.com/appweb/doc/users/configuration.html Also, unless something has changed, setting up `SSLCertificateFile` with a private key signed by a bona fide CA (rather than self-signed) took some jumping-thru-hoops. You can poke around and modify the `ErrorLog` and `Log` specs, but on
  4. Exactly. If we're talking TCP here (we are), rate limiting thru backpressure is what you want by setting `SO_RCVBUF` with `setsockopt()` Buried in vi.lib you can find some methods that take a TCP connection reference and expose the underlying file descriptor -- presumably, you could set such options with kernel APIs (I've not tried) -- but in reality using the labview TCP API is kinda jokey if you're concerned about security (or high performance). Granted, best-in-class security and also high-performance are not the presiding requirement for many applications, in which case the TCP API
  5. This one bit is not quite correct. You're thinking about multiple Event Handler Structures binding to a shared queue created by a single Register For Events Node. That's the scenario that produces undefined behavior. (Not just unpredictable behavior; truly undefined behavior) Multiple Event Handler Structures bound to a "Statically-Registered Event" are OK, but as hooovahh suggests, not usually recommended. --- "Statically-Registered Event" -- contrasted with "Dynamically-Registered Event" -- is just a silly terminology for "magic wires that you don't see that you just 'know' must
  6. Envious should be the wrong word here. Such "arcane issues" should have been made more developer-friendly long, long ago -- these topics definitely feel "foreign" coming from labview, but "arcane" -- we're on the far other end of the spectrum from "arcane" as far as C is concerned here -- this knowledge should be some straightforward day-to-day interop. But it's not, unfortunately. That said ... you'll find relatively few questions unanswered, and will rarely be disappointed, appending "RolfK" to your searches on these topics :-) I had started to type a response here, but it got
  7. This part actually still fascinates me, how labview provides such a clean abstraction over the underlying memory ... ... and you pretty much were able to hit every facet from which my frustrations stem. 1) underpowered interface that 2) never changes that 3) was not dogfooded so 4) it totally blows and therefore so does my developer experience while trying to do something meaningful with the API while 5) NI has their own far more powerful interface, and are therefore unconcerned day-to-day with 1)
  8. Thanks for actually running this and confirming my suspicion; i was just poking thru source code on a 13" macbook air and xcode, and of course couldn't even load the VI or C without compiler error I seem to recall @Darin.K commenting before on the quality of the PRNG in LabVIEW in the past; @ShaunR, perhaps you have demonstrated a better one here!
  9. No prob. First, your statement "nice simple example from NI engineer" threw my BS detector into red-alert mode "space heater" means CPU, polling without any sort of throttle, or more appropriately interrupt-driven procedure, turns into this: https://www.google.com/search?q=%22space+heater%22&tbm=isch Time bug -- publisher waits only long enough to allow "the thing" on the other side of `PostLVUserEvent()` to make a memory copy, but not to reasonably ACK that the event has been processed and the handler is effectively ready for the next event. In other words, publisher is asyn
  10. To be fair, your expectation here is utterly reasonable and desirable. It's the C<->LabVIEW FFI is utterly unreasonable and undesirable, and virtually unchanged since the 1900's.
  11. OK, having downloaded that example; the data posted is allocated on the stack, not on the heap. Major difference. That's why that particular example you cite has no memory leak. But creating a new DSHandle without freeing it -- definitely a memory leak. Now, ideally, `LVPostUserEvent()` would have an additional (boolean) parameter that indicates "take ownership of this data" -- to avoid caller bookkeeping and provide vastly superior performance by not bring the Memory Manager into the mix making a new allocation -- but the LVRT is back in caveman ages, so we are relegated to caveman pr
  12. I directly contest these statements. Provide an executable test case here that indicates what you say is true. *edit: "what RolfK said"
  13. Good luck here! Report back if/when you run into trouble. BTW, I'd tend to lean toward static linking here; it better matches the risk/reward profile in the circumstances you lay out. In terms of performance, static versus dynamic linking is utterly negligible in virtually all application domains -- it's a mostly a matter of your deployment/distribution/upgrade scenarios required by the application.
  14. It's unavoidable, unfortunately. Consider this race condition -- Let's say your wrapper library uses `PostLVUserEvent()` inside the function callback that the main library calls, in order to send the structure represented by `struct tyMessage` (let's ignore alignment and padding for now; do a little hand-wavy thing knowing it's a surmountable prob). What happens on the LabVIEW side? Let's say this goes into a Register For Events queue and is handled by an event structure. This means, the handling of the event is asynchronous from the callback from the main library. Feel free to
  15. Not so fast, friend ... First, can you provide some representative examples of say, some of the more complex functions you intend to invoke from LabVIEW? Also, it would help to know some basic timing diagrams and synchronization requirements between lv and the shared lib; e.g., are function callbacks spray-and-pray, or does the library routine invoking them expect synchronous return values or manipulations of arguments passed as pointers? Ideally, provide a header file, or a good smattering of function declarations, anonymizing variable names into `a`, `b`, etc. if necessary. A
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.