On Jun7, 2012, at 12:08 , Sandro Santilli wrote:
> On Thu, Jun 07, 2012 at 12:00:09PM +0200, Florian Pflug wrote:
>> On Jun7, 2012, at 10:20 , Sandro Santilli wrote:
>
>>> In that case I can understand Tom's advice about providing a callback,
>>> and then I would only need to perform the "events flushing" part of
>>> from within the callback, and only for windows.
>>
>> Why would you need a signal handler in the library at all, then? Just
>> test the same flags that CHECK_FOR_INTERRUPTS does in the callback, and
>> call your interrupt request method if they indicate "abort". (Or, slightly
>> cleaner maybe, allow the callback to abort processing by returning false)
>
> I'm just afraid that invoking a callback (from a library to user code)
> could be significantly slower than simply lookup a variable, especially
> if the interruption checking is performed very frequently. But maybe I'm
> being overparanoid.
It's definitely slower, probably at least an order of magnitude. But you
don't have to call that callback very often - once every few hundred
milliseconds is already more then plenty. Isn't there a place in the library
where you could put it where it'd be called with roughly that frequency?
IMHO the advantage of not messing with signal handling in the library
is more than worth the slight overhead of a callback, but YMMV.
best regards,
Florian Pflug