[GRASS5] 5.7: XDRIVER modification - CPU load

Glynn Clements glynn.clements at virgin.net
Wed Mar 24 12:50:51 EST 2004


Markus Neteler wrote:

> > In any case, a busy-wait (repeated non-blocking calls in a loop)
> > definitely isn't the solution. The only sensible approach is to use
> > select() on both the X descriptor and the driver socket. Get_Xevent()
> > already does this; I suggest using it; like 5.0/5.3 do.
> 
> Using select() and friends seems to be the (temporal) solution unless
> someone writes a new display driver. Unfortunatelty I don't know
> how to change that. The reasons why select() etc are not used 
> I cannot remember (if it was ever posted).

FWIW:

Even if someone does write a new display driver, select() (or poll(),
which serves essentially the same purpose) will still be the solution.

If you don't use select/poll, you're reduced to either:

a) blocking on the X connection,
b) blocking on the client connection,
c) manual polling, i.e. making both descriptors non-blocking and
checking them continuously, or
d) as for c), but sleeping in between checks.

The problems with the above are:

In case a), if the client terminates, the driver will still be waiting
for the user to press a mouse button; other clients won't be able to
connect until that happens. [This is what XDRIVER used to do.]

Case b) isn't an option for the Get_location_with_* functions; normal
operation involves X button events occurring before the client
terminates.

Case c) will result in the driver consuming all available CPU cycles. 

Case d) avoids the CPU-hogging at the expense of introducing a delay
between the event occurring and the driver handling it.

The only approach which doesn't have any of these drawbacks is to
block until either an X event is received via the X connection or the
client terminates (resulting in EOF on the client connection). IOW,
select() or poll().

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-dev mailing list