I'm having trouble with a process taking too long, and holding up other processes. Basically, the process produces a bitmap showing a map of the geographical position, with a number of feature plotted. Whilst this is going on, data from a GPS receiver is being displayed on screen. These are separate processes. However, when the map is being produced, the data display freezes. Once the map is finished, the data display continues as if nothing happened. I've tried running the mapping process under nice, with a priority value of 20 (minimum), but this has made no significant improvement. Is there a way to limit the processor time that a process can take - say specifying that the process cannot exceed 20% processor time? Many thanks, Stuart -- --------------------------------------- Stuart Bailey BSc (hons) CEng CITP MBCS LinuSoft (Owner) Linux Specialist (0845) 6583563 http://www.linusoft.co.uk ----------------------------------------
Stuart Bailey wrote:
I'm having trouble with a process taking too long, and holding up other processes.
Basically, the process produces a bitmap showing a map of the geographical position, with a number of feature plotted. Whilst this is going on, data from a GPS receiver is being displayed on screen. These are separate processes.
However, when the map is being produced, the data display freezes. Once the map is finished, the data display continues as if nothing happened.
I've tried running the mapping process under nice, with a priority value of 20 (minimum), but this has made no significant improvement. Is there a way to limit the processor time that a process can take - say specifying that the process cannot exceed 20% processor time?
Many thanks, Stuart
This is probably not a Linux kernel scheduling issue but rather an X-windows scheduling one. X windows runs cooperative event queues for each application accessing the display. If one application does not relinquish control to the X windows queue it will prevent graphic operations by other x programs. It looks like the bit map drawing process is badly behaved i.e. does not relinquish control to X. Depends what language it is written in as to the solution but if you have access to the code you might consider inserting a Do_Events X call or its equivalent after every so often in the bit map drawing routine. Ian
On 09-Apr-07 18:57:51, Ian bell wrote:
Stuart Bailey wrote:
I'm having trouble with a process taking too long, and holding up other processes.
Basically, the process produces a bitmap showing a map of the geographical position, with a number of feature plotted. Whilst this is going on, data from a GPS receiver is being displayed on screen. These are separate processes.
However, when the map is being produced, the data display freezes. Once the map is finished, the data display continues as if nothing happened.
I've tried running the mapping process under nice, with a priority value of 20 (minimum), but this has made no significant improvement. Is there a way to limit the processor time that a process can take - say specifying that the process cannot exceed 20% processor time?
Many thanks, Stuart
This is probably not a Linux kernel scheduling issue but rather an X-windows scheduling one. X windows runs cooperative event queues for each application accessing the display. If one application does not relinquish control to the X windows queue it will prevent graphic operations by other x programs. It looks like the bit map drawing process is badly behaved i.e. does not relinquish control to X. Depends what language it is written in as to the solution but if you have access to the code you might consider inserting a Do_Events X call or its equivalent after every so often in the bit map drawing routine.
Ian
Hmmm -- interesting comment! One learns new things every day ... Hadn't realised that X could have trouble walking and chewing gum at the same time! If that is the case, is there any possiblility of writing a "back end" (in some language) that would take input from the two processes in question, combine them, and send a joint graphic display to X? Then X would only need to chew gum? Best wishes to all, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 09-Apr-07 Time: 20:39:59 ------------------------------ XFMail ------------------------------
(Ted Harding) wrote:
On 09-Apr-07 18:57:51, Ian bell wrote:
Stuart Bailey wrote:
I'm having trouble with a process taking too long, and holding up other processes.
Basically, the process produces a bitmap showing a map of the geographical position, with a number of feature plotted. Whilst this is going on, data from a GPS receiver is being displayed on screen. These are separate processes.
However, when the map is being produced, the data display freezes. Once the map is finished, the data display continues as if nothing happened.
I've tried running the mapping process under nice, with a priority value of 20 (minimum), but this has made no significant improvement. Is there a way to limit the processor time that a process can take - say specifying that the process cannot exceed 20% processor time?
Many thanks, Stuart
This is probably not a Linux kernel scheduling issue but rather an X-windows scheduling one. X windows runs cooperative event queues for each application accessing the display. If one application does not relinquish control to the X windows queue it will prevent graphic operations by other x programs. It looks like the bit map drawing process is badly behaved i.e. does not relinquish control to X. Depends what language it is written in as to the solution but if you have access to the code you might consider inserting a Do_Events X call or its equivalent after every so often in the bit map drawing routine.
Ian
Hmmm -- interesting comment! One learns new things every day ... Hadn't realised that X could have trouble walking and chewing gum at the same time!
If that is the case, is there any possiblility of writing a "back end" (in some language) that would take input from the two processes in question, combine them, and send a joint graphic display to X? Then X would only need to chew gum?
Not sure. It would be better to fix the badly behaved application. What are the two apps you are using? Ian
Hi Ian, Actually, I'm not using X. The app that produces the bitmap is essentially ghostscript converting from ps to bmp using the bmp16m filter. When gs runs, the application (which displays graphical data directly using the frame buffer, under QT) stop updating. That is why I was looking for a kernel type solution. Many thanks, Stuart. Ian bell wrote:
(Ted Harding) wrote:
On 09-Apr-07 18:57:51, Ian bell wrote:
Stuart Bailey wrote:
I'm having trouble with a process taking too long, and holding up other processes.
Basically, the process produces a bitmap showing a map of the geographical position, with a number of feature plotted. Whilst this is going on, data from a GPS receiver is being displayed on screen. These are separate processes.
However, when the map is being produced, the data display freezes. Once the map is finished, the data display continues as if nothing happened.
I've tried running the mapping process under nice, with a priority value of 20 (minimum), but this has made no significant improvement. Is there a way to limit the processor time that a process can take - say specifying that the process cannot exceed 20% processor time?
Many thanks, Stuart
This is probably not a Linux kernel scheduling issue but rather an X-windows scheduling one. X windows runs cooperative event queues for each application accessing the display. If one application does not relinquish control to the X windows queue it will prevent graphic operations by other x programs. It looks like the bit map drawing process is badly behaved i.e. does not relinquish control to X. Depends what language it is written in as to the solution but if you have access to the code you might consider inserting a Do_Events X call or its equivalent after every so often in the bit map drawing routine.
Ian
Hmmm -- interesting comment! One learns new things every day ... Hadn't realised that X could have trouble walking and chewing gum at the same time!
If that is the case, is there any possiblility of writing a "back end" (in some language) that would take input from the two processes in question, combine them, and send a joint graphic display to X? Then X would only need to chew gum?
Not sure. It would be better to fix the badly behaved application. What are the two apps you are using?
Ian
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
-- --------------------------------------- Stuart Bailey BSc (hons) CEng CITP MBCS LinuSoft (Owner) Linux Specialist (0845) 6583563 http://www.linusoft.co.uk ----------------------------------------
Stuart Bailey wrote:
Hi Ian, Actually, I'm not using X. The app that produces the bitmap is essentially ghostscript converting from ps to bmp using the bmp16m filter. When gs runs, the application (which displays graphical data directly using the frame buffer, under QT) stop updating.
So gs is not actually drawing a bitmap but simply creating one in memory or a file somewhere.
That is why I was looking for a kernel type solution.
If gs is not drawing then a kernel solution is exactly what you need. Ian
On 4/9/07, Stuart Bailey <stuart@linusoft.co.uk> wrote:
Hi Ian, Actually, I'm not using X. The app that produces the bitmap is essentially ghostscript converting from ps to bmp using the bmp16m filter. When gs runs, the application (which displays graphical data directly using the frame buffer, under QT) stop updating.
That is why I was looking for a kernel type solution.
Just to check - it's only your application which is frozen - the rest of X is fine? Sounds like your application is single threaded and is stopped until gs returns with the results. Nothing the kernel can do about that! The app needs to be changed to either wait in a different thread, or to poll for the results while still processing X events - depends on how gs is called. Hope this helps, Tim.
participants (4)
-
Ian bell -
Stuart Bailey -
ted.harding＠nessie.mcc.ac.uk -
Tim Green