Re: [Tcpreplay-devel] threading and abort/suspend

[Abdelrazak Y. <you...@gm...>]

Aaron Turner wrote:
> On Wed, Sep 30, 2009 at 10:21 AM, Abdelrazak Younes
> <you...@gm...> wrote:
>> Aaron,
> 
>> My first thought is why? Why not just let the application developer handle
>> his thread?
>>
>> I've been using libpcap functions lately in a Qt GUI program and I just
>> needed to launch my libpcap function inside a QThread (I used QtConcurrent).
>>
>> The same could also be true for timers of course. Which means that you would
>> reuse the Qt event loop instead of your own.
> 
> Basically, writing the timers for each platform and event looping is
> something which I've spent a fair bit of time working on to work as
> best as possible, and expecting any other developer to have to
> re-invent the wheel seems broken.  Most solutions are at best 1usec
> accuracy (many only accurate to 10ms) which without a fair bit of
> effort aren't good enough for many users.

OK, that's an excellent argument, which I was of course not aware of.

> 
>> So my recommendation would be that the lib API focuses on the low level
>> ethernet sending/reading and let the application do the thread creation and
>> management.
> 
> Then basically people should just use libpcap/winpcap (which provides
> a cross-platform means to read & write packets) and not use this API.
>   Sure maybe they want packet editing, but they can already grab the
> tcpedit code which has it's own API today.

Makes sense indeed.

> Anyways, to be clear, I'm *not* suggesting the tcpreplay API do any
> thread management.  Rather it is up to the application to manage
> threads as tcpreplay_replay() blocks until complete or until
> tcpreplay_abort() is called in another thread (both threads
> created/managed by the main application).
> 
> Right now, I don't have any plans for a event loop based API (like
> libevent) since single threaded event loops like that don't provide
> enough control over timing.
> 
>> Of course you can also provide a higher level API for programs
>> that do not want to bother with thread creation; and the tcpreplay console
>> program for example would use that high level API. And your proposed API
>> above fits quite well in this scheme. But I would also offer a lower level
>> API as outlined above.
> 
> Non-multithreaded apps in my model would block on tcpreplay_replay()
> and not support the tcpreplay_abort() call (unless they handled it via
> a timer or signal handler).

Right, I agree of course.

Thanks for the added explanations.

Abdel.