[redland-dev] Multi-Threading Redland
Nicholas J Humfrey
njh at aelius.com
Sun Feb 14 21:26:25 CET 2010
> Hello,
>
> Yesterday I released RedStore version 0.1:
> http://code.google.com/p/redstore/
>
> I decided to keep the first release simple, and it can only handle a
> single request at a time.
>
> Is Redland multithreadable? Are all the storage model
> multithreadable? Are there any examples of this?
>
> Should the librdf_world, librdf_storage and librdf_models structures
> be shared between threads?
>
>
> Thanks,
>
> nick.
I have spent some time with Google and the redland-dev mailing list
archives and it looks like thread support in Redland is limited and
largely unused/untested.
Options for RedStore:
0) Only process a single request at a time
- RedStore's aim is to be lightweight and does this now
- Pro: simple and uses mimum memory
- Pro: no problems with locking
- Pro: very fast for a single client
- Pro: works with all storage models
- Con: slow at responsing to multiple simultanious requests
1) Use select() for IO muliplexing.
- Pro: very efficent, only uses a single process
- Con: not sure this would work well with Redland due to lack of main
select() loop.
- Con: can make codebase difficult to understand
2) Use fork() before responding to each request
- Pro: very simple and mostly portable
- Pro: doesn't use lots of memory while waiting for a request
- Con: have to wait for new process to start even for a lightly loaded
system
- Con: would not work for memory based storage
3) Have a pre-fork() pool of processes
- Pro: faster response time than basic fork()
- Con: lots of processes sitting in memory
- Con: more complex
- Con: still would not work for memory based storage
4) Use a threading based model
- Pro: faster response time than basic fork()
- Pro: works with memory based storage
- Con: Redland codebase isn't thread optimised?
- Con: may end up blocking lots while waiting for other threads
- Con: maybe difficult to debug
- Con: not well tested
5) Something else?
Does anyeone have any suggestions or opinions?
Thanks,
nick.
More information about the redland-dev
mailing list