Sorry again. I've been distracted and did not read to the end of your message.
Am 11.08.2015 um 15:39 schrieb Antonio Scuri: > Ok. Now I see. > > IupFlush is usually used when you need to processes messages after > changing elements attributes that need to be updated by the system. > > I would recommend using IupMainLoop and something else for the database > connections, not the way around using IupFlush. > > There are several ways how to pool secondary systems: > > - Use a second thread to processes it (frequently used) That's the "complicated" way I can see. Have an embeddes Lua-Interpreter executed dynamically generated Lua code. > - Use a IupTimer to check from time to time if there is something to be > processed on it (limited by a minimum time interval for not too fast > processing) That's what we startet with. But since I can't make the timer return "right now", it will hopelessly slow down the application. To no usable. Example: e few hundred results to be read from the database and display in a matrix. Takes forever while Iup is sitting most of the time in idle until the timer will check for i/o and notice a new item. > - Use the IDLE callback to process it (high CPU use since it will be > running all the time) As you said: that's the CPU hook. I read that in the docs and thought there must be a better way. Sorry again for the incomplete reply before. /Jörg > > Best, > Scuri > > > > > On Tue, Aug 11, 2015 at 10:11 AM, "Jörg F. Wittenberger" < > joerg.wittenber...@softeyes.net> wrote: > >> Sorry for following up on my own message. >> >> I just considered the problem again and got stuck. >> >> Am 11.08.2015 um 14:04 schrieb "Jörg F. Wittenberger": >>> Am 10.08.2015 um 19:20 schrieb Antonio Scuri: >>>> Well, I really don't know. >>>> >>>> Just know that the calls are not actually "active all at the same >> time". >>>> When you call IupFlush in one of them, it will stop that one, processes >> the >>>> pending messages one by one, then return to that one. If that can occur >>>> recursively then it is a real nightmare to manage. You will have a hard >>>> time to know what is the order that things are happening. >>> >>> Ah' I see. >> >> Maybe I don't really see. >> >> So when exactly SHOULD I call IupFlush? Which one is the strategy >> natural to Iup. Changing the app side of things is simple. There is >> not so much to change by now. I'm still exploring/learning the toolkit. >> >> So far the first strategy I tried was to simply run IupMainLoop and call >> Iup functions from the callbacks. >> >> This did work as long as there Iup was the only source of events to be >> considered. But there is some i/o going on (database connections etc.). >> So I switched to the next strategy : >> >> 2nd: In a loop >> 1. Call all Iup* things to build the GUI as app logic suggests at this >> point in time. >> 2. Call IupFlush. (Former version: call IupLoopStep and IupFlush if >> that does not return IUP_CLOSE, but that seemed to add no value over >> just IupFlush.) >> 3. Poll other I/O for a moment. Goto 1 processing the results. >> >> This did work most of the time, but sometimes it would just not result >> in updates as expected. Turned out some calls (I don't recall which one >> it where) would executed in (1.) call callbacks again. (I recall having >> read about this in the docs, so no surprise here so far.) >> >> At this point I had to do wild guess work how I should handle this. >> >> Option A: Record the callbacks job to be execute later and return >> immediately. >> Option B: Execute the Job right now. >> >> The former resulted eventually in the segfaults during IupFlush in step >> (2). To I settled so far on Option B. But this required me to Call >> IupFlush also in the recursive invocation. >> >> >> So, to repeat myself: which strategy is natural to Iup? >> >> When must I call IupFlush? >> >> As I'm reading your reply, I'd understand that calling IupFlush from >> withing callbacks is no good idea, correct? >> >> If so: how would I make those changes take effect? Because: if I call >> "too many" (whatever that is _I_ have no way to know) Iup* things (e.g. >> IupDestroy) from within a single callback, then I get the segfault. >> >> >> Thanks so much >> >> /Jörg >> >> >>> >>> Maybe it's a good idea to add a remark pointing this out in the manual. >>> Me, reading the manual, gathered that calling IupFlush would never >>> hurt, just advance the processing at the Iup side of things. >>> >>>> I would recommend you to get a step back are rethink that strategy. >>> >>> So far this never became a strategy. It failed straight in the first >>> experiment. It's just my missunderstanding of the docs and an >> experiment. >>> >>>> Independent from IUP, or other toolkits, what you are trying to >> implement? >>> >>> There is a very simple RDF/DublinCore inspired inventory application for >>> a small archive (archive of physical things, kind of a museum - not the >>> family of file formats). I'm using it as "personal wiki" for my notes >> too. >>> >>> The original is a web app. I'm trying replace the Web-Interface with a >>> native GUI. >>> >>> /Jörg >>> >>> >>>> Best, >>>> Scuri >>>> >>>> >>>> On Sat, Aug 8, 2015 at 9:58 AM, "Jörg F. Wittenberger" < >>>> joerg.wittenber...@softeyes.net> wrote: >>>> >>>>> ((Sorry, this is not exactly the message I want to reply to, but at >>>>> least it's the correct thread. (The other message is already gone >> here.))) >>>>> >>>>> I managed to understand the problem a little better. >>>>> >>>>> Maybe I'm dong something against the philosophy of correct Iup usage >> here? >>>>> >>>>> What's happened is that the action callback from my apps back-button is >>>>> called as often as I click it. Eventually my action callback will also >>>>> call IupFlush. (Is this a No-No?) This IupFlush in turn enables the >>>>> next action callback to be activated. Thus there are 4-5 calls active >>>>> at the same time. >>>>> >>>>> Each of those calls does essentially the same: recreate scrollbox full >>>>> of controls (from different data sets). Then detach the (only) child >> of >>>>> the target container, IupDestroy that detached child, IupAppend the new >>>>> one and IupRefresh the container. >>>>> >>>>> Since the data set is different, those action callback take a different >>>>> amount of time (while waiting for the data base etc.). >>>>> >>>>> By throwing in some additional calls to IupFlush into the code (I'd >>>>> believe this _should_ not hurt, shouldn't it?) I've been able to get it >>>>> all mixed up. Up to the point that controls belonging to different >> data >>>>> sets / callbacks ended up mixed into the same container. >>>>> >>>>> To put it in other words: those nested action callbacks in combination >>>>> with IupFlush enabled me to (accidentally) implement a kind of green >>>>> threads on top of Iup. Unfortunately without proper locking. >>>>> >>>>> Having too few IupFlush's there will result in the segfault. More >>>>> flushes make it appear to work. Even more flushes confuse the layout >>>>> logic. >>>>> >>>>> How should this being done right? >>>>> >>>>> Thanks >>>>> >>>>> /Jörg >>>>> >>>>> Am 05.08.2015 um 10:50 schrieb "Jörg F. Wittenberger": >>>>>> Hi Antonio, >>>>>> >>>>>> during IupFlush my program dumped a core like this: >>>>>> >>>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from >>>>>> /usr/local/lib/libiup.so >>>>>> (gdb) bt >>>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from >>>>>> /usr/local/lib/libiup.so >>>>>> #1 0x00000000 in ?? () >>>>>> >>>>>> >>>>>> Anything I can do to help debugging that one? >>>>>> >>>>>> Best >>>>>> >>>>>> /Jörg >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Iup-users mailing list >> Iup-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/iup-users >> >> > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > ------------------------------------------------------------------------------ _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
