Re: [Libsigcx-main] Signal Queue Length

[Roland W. <ro...@mm...>]

On Monday 23 June 2003 1:32 pm, Andreas Rottmann wrote:
> Roland Welker <ro...@mm...> writes:
> > Hi,
> >
> > I am working on a project, where I send Signals between threads in a non
> > blocking way.
> > However, I would like to know, how many SIgnals are currently in the
> > queue:
> >
> > The application would be something like if n signals have been queued,
> > block the next call (or fail it), or, even better, emit a signal to my
> > self (emitting thread).
>
> Well, the number of signals pending could be counted and provided via
> a Tunnel method. I'm not really sure if this really make sense, since
> there is already a (not exactly specifiable) maximum number of pending
> signals, since the callback info (about 2 machine words) is written to
> a pipe which doesn't have unlimited buffer space (so further signals
> will block).
>
> To convince me to implement this, I'd like to hear a real example
> where this behaviour is useful or needed.
>

Fairly simple, one thread holds a GUI (i.e. is the complete user interface), 
the other task(s) is(are) executing the "hard work". The plan was, that the 
GUI is completly independend (and non blocking) of the functionality. The 
problem is, that some calculations might take a longer time (non of the 
current implemented one has this problem, but you never knwo:-)). 
Furthermore, I want to avoid, that a user starts clicking around, if there 
seems nothing to happen any more. 
Conclution, after n signals have been queued, a simple message to the user, 
informing him, that there are currently jobs processed, and giving him the 
option to queue more, or wait till the queue is empty again.

Roland


> Regards, Andy

-- 
Roland Welker
System Administrator
MMS Graphics
6 Tyock Ind. Est
Elgin, Moray IV30 1XY