On 03/22/2013 10:47 PM, Joachim Schimpf wrote: > On 22/03/2013 18:47, Gesche Gierse wrote: >> Hello, >> >> I'm currently using ECLiPSe embedded in a C++ project and I'm facing >> some problem with sending events from C++ to ECLiPSe. >> >> The C++ project has various threads, some running continuous, others >> only for some time. The ECLiPSe context is initialized within one of the >> continuous threads. >> However the ECLiPSe program I want to run needs to call an predicate >> whenever the control-thread is running (this is one of the >> none-continuous threads). So I post an event to the ECLiPSe context >> every time the control-thread is running. >> >> Everything compiles just fine, and for like a minute it will run the way >> it should, but at some time I always get a "Bogus event queue >> notification in next_posted_event()"-error. >> >> So my question is, is this a threading problem? Does posting events not >> work well, when used in a thread that is non-continuous? > Yes, this is very likely a threading problem. The current event posting > mechanism is not designed for thread communication. > > Could you briefly explain a few more details about your architecture, > so we can suggest an alternative solution: > Does your ECLiPSe thread process jobs that it receives via these events? > If yes, are these jobs then queued, or interrupt each other? > Is the event simple, or are you passing any data (arguments, etc) > along with the event notification? Or is it just an abort-event? > The event is quite simple. In general the C++ threads belong to a cycle: sense, think, act. Eclipse should do the "think" part, so the event I'm passing simply tells ECLiPSe, that it's the start of the "think"-phase, and therefore it can read the sensor data which are up to date at that point (no arguments needs to be passed). It's simply an timing thing. I used a solution with event_after_every at first, but I would rather like to sync it with the C++ threads. Farewell, GescheReceived on Sun Mar 24 2013 - 17:46:50 CET
This archive was generated by hypermail 2.2.0 : Tue Apr 02 2013 - 06:16:31 CEST