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.
I did not get that. What does "something else" suggest? Anyway, I need any one way to synchronize Iup with other activity. So there must be either a way to make IupMailLoop call something (or alternatively "call" return) _right_now_ because of other [like i/o] state change. Or I need a (documented) way to poll a file descriptor (the alternative discussed recently). To make things worse: the framework I'm using does not like pthreads very much. It's all in one thread. While that's good to make things easier to implement/debug/reason about, it forces me to do the i/o poll(2)ing in the same thread as Iup runs. We're currently discussing ways how this could be changed, but it essentially translates into Iup being run in it's own pthread and passing dynamically produced lua code instead of calling the corresponding C functions directly. I'm not yet convinced that this is going to be simpler. Best /Jörg > > There are several ways how to pool secondary systems: > > - Use a second thread to processes it (frequently used) > - 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) > - Use the IDLE callback to process it (high CPU use since it will be > running all the time) > > 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
