Am 25.07.2015 um 16:02 schrieb Antonio Scuri: > Never used poll before, but if you what to block system execution then I > suggest you to do it in another thread.
I had a look at the Iup code. Seems that supporting such an interface is not as easy as I imagined. > IupTimer will not work if the main/step functions are not being called. Yes. I did call them. My problem is: when to call the single step function. Inside the timer I had problems. Somehow it just did not do anything. Seems I must always return into the main loop to see any progress? > If you could call pool function inside a loop with a short wait time, > then inside that loop call IupLoopStep and the system will be responsive. That's the busy loop I wrote and rewrote. It works, but it does not work well. Too much system load or not responsive. What I could do would be to run IUP in one thread and the polling in another. But then, how would I communicate from the polling thread to IUP? I'm fairly certain that just calling IUP functions would ran havoc. I'd need to pause the IUP thread until the polling thread is done calling IUP functions. To do so, I'd again end up with a thread in a busy loop calling IupLoopStep and then pausing for a while. Possible, but dissatisfying. I'm going to do so, but first I want to be certain that I'm not overlooking some better way. Thanks /Jörg > > Best, > Scuri > > > > On Sat, Jul 25, 2015 at 5:54 AM, "Jörg F. Wittenberger" < > joerg.wittenber...@softeyes.net> wrote: > >> Hi Antonio & all, >> >> these days I wrote, changed, rewrote, modified etc. an ugly piece of >> code. A workaround for me not knowing how to integrate Iup with a >> poll(2) based message loop. >> >> All I could come up with where variations of a busy loop. And thus I >> ended up with two IupVal controls to trade responsiveness for CPU load. >> >> I'm seeing IupTimer as the "intended" thing to use here. Thus the >> application is essentially only running in the timer callback. >> >> This is mostly ok. Except it is not. The problem is: the message loop >> wants to sit in poll(). If it does not, then i/o is delayed until the >> next check. >> >> Therefore the app feels sluggish, since it does not react to i/o in >> time. (Except for very short timer periods.) >> >> Worse the situation becomes if there is a lot of fast, local i/o going >> on; like when accessing a database. I've seen this timer becoming the >> bottleneck. >> >> The alternative is to frequently call IupMainLoopStep. This too results >> in an unacceptable high load. Also it seem not to really work from the >> timer in all cases. >> >> >> So what would be "the solution"? >> >> The best thing I could hope for would be if I could ask Iup for a file >> descriptor to listen on. Whenever data is ready to read on this fd, I >> would know that Iup wants to become active and I should call the stepper >> until it eat up all this input. >> >> I guess this would not be all to hard to implement at the Iup side. >> >> But maybe there is a better solution I don't see? >> >> Thanks >> >> /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
