Re: [Iup-users] Integrating Iup with poll(2) based message loop
> Which driver are you using? Windows? > I'm currently struggling. It just does not want to work. Yes, only Windows. (NB: Your poll() and GUI stuff should be processed in one main thread.) I used same approach on Linux with other GUI toolkit: - get socket descriptor from toolkit and add it to your poll(); - process all UI events of toolkit, when socket becomes readable. -- Nodir -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Which driver are you using? Windows? I'm currently struggling. It just does not want to work. Am 27.07.2015 um 16:29 schrieb Nodir Temirkhodjaev: >> I thought that the docs mentioned that IupLoopStep would be *no* >> substitute to running the main loop. > >> Actually I recall having tried this and found out the hard way. But >> apparently it works for you. So I shall retry. > > Works for me: > === > if iup.LoopStep() == iup.CLOSE then > evq:stop() > end > iup.Flush() > === > > -- Nodir > > > -- > ___ > 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
Re: [Iup-users] Integrating Iup with poll(2) based message loop
> I thought that the docs mentioned that IupLoopStep would be *no* > substitute to running the main loop. > Actually I recall having tried this and found out the hard way. But > apparently it works for you. So I shall retry. Works for me: === if iup.LoopStep() == iup.CLOSE then evq:stop() end iup.Flush() === -- Nodir -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Am 27.07.2015 um 15:54 schrieb Nodir Temirkhodjaev: >> Somehow my attempts to do something alike (though I'm using the gtk >> version on Linux), fail. > >> The point is: where to run the IupLoopStep, ~flush etc. > >> I gather that should be done from the same thread running the >> IupMainLoop. Therefore the only way is to run those from a callback. >> Correct? > > No. Don't use IupMainLoop(). Ah! I thought that the docs mentioned that IupLoopStep would be *no* substitute to running the main loop. Actually I recall having tried this and found out the hard way. But apparently it works for you. So I shall retry. > You should add IUP's socket descriptor to your poll() to wait readable state. > Then run IupLoopStep() etc, when event triggers. > (I assume you added "XSOCKETFD" attr.) -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
> Somehow my attempts to do something alike (though I'm using the gtk > version on Linux), fail. > The point is: where to run the IupLoopStep, ~flush etc. > I gather that should be done from the same thread running the > IupMainLoop. Therefore the only way is to run those from a callback. > Correct? No. Don't use IupMainLoop(). You should add IUP's socket descriptor to your poll() to wait readable state. Then run IupLoopStep() etc, when event triggers. (I assume you added "XSOCKETFD" attr.) -- Nodir -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Am 27.07.2015 um 12:48 schrieb Nodir Temirkhodjaev:
> Monday, July 27, 2015, 3:07:18 PM, Jörg F. Wittenberger wrote:
>> Am 25.07.2015 um 16:24 schrieb Nodir Temirkhodjaev:
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.
>
>>> We need new global attribute (maybe "XSOCKETFD"),
>>> which will contain result of ConnectionNumber(iupmot_display).
>
>> Alike.
>> But this one would only work for Motif, wouldn't it?
>
> Similar in gtkSetGlobalAttrib():
> IupSetGlobal("XSOCKETFD", ConnectionNumber(xdisplay));
>
> My usage of IUP with poll()-like based message loop in Windows:
> https://github.com/tnodir/wipf/blob/master/bin/lua/main.lua#L64
Somehow my attempts to do something alike (though I'm using the gtk
version on Linux), fail.
The point is: where to run the IupLoopStep, ~flush etc.
I gather that should be done from the same thread running the
IupMainLoop. Therefore the only way is to run those from a callback.
Correct?
If so, it should be OK to run them from a timers action callback.
But whatever I try, it looks as if nothing took effect until this very
timer callback returns to the main loop. (Which means that I can skip
the magic, the main loop itself would suffice.)
I'm confused.
--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
I see. This should do the trick.
Agreed, that's what we'd need in Iup.
/Jörg
Am 27.07.2015 um 12:48 schrieb Nodir Temirkhodjaev:
> Monday, July 27, 2015, 3:07:18 PM, Jörg F. Wittenberger wrote:
>> Am 25.07.2015 um 16:24 schrieb Nodir Temirkhodjaev:
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.
>
>>> We need new global attribute (maybe "XSOCKETFD"),
>>> which will contain result of ConnectionNumber(iupmot_display).
>
>> Alike.
>> But this one would only work for Motif, wouldn't it?
>
> Similar in gtkSetGlobalAttrib():
> IupSetGlobal("XSOCKETFD", ConnectionNumber(xdisplay));
>
> My usage of IUP with poll()-like based message loop in Windows:
> https://github.com/tnodir/wipf/blob/master/bin/lua/main.lua#L64
>
> -- Nodir
--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Monday, July 27, 2015, 3:07:18 PM, Jörg F. Wittenberger wrote:
> Am 25.07.2015 um 16:24 schrieb Nodir Temirkhodjaev:
>>> 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.
>> We need new global attribute (maybe "XSOCKETFD"),
>> which will contain result of ConnectionNumber(iupmot_display).
> Alike.
> But this one would only work for Motif, wouldn't it?
Similar in gtkSetGlobalAttrib():
IupSetGlobal("XSOCKETFD", ConnectionNumber(xdisplay));
My usage of IUP with poll()-like based message loop in Windows:
https://github.com/tnodir/wipf/blob/master/bin/lua/main.lua#L64
-- Nodir
--
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
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
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Am 25.07.2015 um 16:24 schrieb Nodir Temirkhodjaev: >> 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. > > We need new global attribute (maybe "XSOCKETFD"), > which will contain result of ConnectionNumber(iupmot_display). Alike. But this one would only work for Motif, wouldn't it? -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
> 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. We need new global attribute (maybe "XSOCKETFD"), which will contain result of ConnectionNumber(iupmot_display). -- Nodir -- ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Integrating Iup with poll(2) based message loop
Never used poll before, but if you what to block system execution then I suggest you to do it in another thread. IupTimer will not work if the main/step functions are not being called. 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. 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] Integrating Iup with poll(2) based message loop
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
