[botan-devel] Threaded Filters/Operation Parallelisation

Joel Low joel at joelsplace.sg
Tue Apr 24 05:07:18 EDT 2012

Hello all,

Recently I've been playing with the idea of having a threaded Fork filter to 
be used together with Pipe: processing for each subsequent filter downstream 
of the threaded Fork filter is done in a separate thread of its own. This 
could potentially bring performance benefits (in theory) especially with a 
move on to having an increasing number of computing cores per CPU.

So I've emailed Jack separate to the list to get some of his opinions. The 
main points he raised were that:

 - The approach used for Fork would be most promising in terms of working with 
the current design and not forcing a full rewrite of the filter system.
 - He proposed defining a new Filter subclass Threaded_Filter which itself 
takes a Filter* as an argument which will spawn a thread and uses two message 
queues for I/O with the filter it manages.
 - When write() is called on the Threaded_Filter, it pushes it to the input 
queue, which the worker thread pulls off and write()s to the underlying 
 - With this approach the application can control concurrency very finely 
(perhaps too finely), since the application can specify which filters run on 
the main thread, and what runs on a secondary thread.

I was leaning to a slightly different approach: with the knowledge that Fork 
operations parallelise the easiest, I should adapt the Fork class to let each 
downstream filter run in a separate thread. This shares much commonality in 
its design with Jack's idea (especially in terms of thread sync and
friends), provides a little less control over what runs in a separate thread, 
but comes with a slightly easier implementation.

Jack stated that I probably should email the devel list and solicit ideas, 
since everyone may have different expectations. I'll be implementing this in 
my spare time so I'd like to accept as many ideas and combine them before 
acting on it. I think that the pipe/filter design Botan has is intuitive, and 
I'd like to keep that as much as possible, without compromising on potential 
performance gains. Intuitively, both seem to run contrary to each other, but I 
think we can work something out here to an API that is both powerful yet 
easily mastered.

Any thoughts?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6547 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20120424/e75876dc/attachment.p7s>

More information about the botan-devel mailing list