Andreas,
thank you for your fast response.
I'm seriously thinking of using 'your' lib for an ambitious project, so
it is nice to see there is some life here...
BTW: *visible* event based programming for synchronizing threads and
communication between them is new for me regarding C++: I've used it
unvisibly while programming a VC++ GUI some time ago though (at least I
think so ;-) ) and I've some experience with C++ thread programming.
Greetings,
Stephan
Andreas Rottmann wrote:
> Stephan Rudlof <sr...@ev...> writes:
>
>
>>> Roland Welker <roland@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).
>>
>>If I've understood correctly, signals can be many kinds of C++-objects.
>>Is there a limitation in their size? If so: is there a possibility to
>>get the limits (for inner thread and between threads cases)?
>>
>
> There is no size limit, as the callback is passed as a pointer. There
> is only an inherent limit of the number of signals that can be in the
> queue at a given time due to the use of a pipe.
>
> Andy
--
Stephan Rudlof (sr...@ev...)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
|
