Copying the entire database for each thread is about 500MB of space per thread, but it seems to be working. There is definitely some kind of block, after seeing this. However, I don't think it is a system block because I was able to put 4 blast queries into a loop in the bash shell and fork them, and top showed all four running at the same time.
| [reply] |
However, I don't think it is a system block because I was able to put 4 blast queries into a loop in the bash shell and fork them, and top showed all four running at the same time.
That really doesn't make any sense at all.
When you spawn blast from several threads, the blast instances are running as separate processes, so should be completely unaffected by anything in the parent process, regardless of whether it is using threads or not.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
500 MB? Have you looked at the hard drive light? I suggest a memory mapped read only file shared among processes or threads if read-only mode can work for you.
| [reply] |
ithread interps never clean up after themselves after exiting and memleak. I believe there is a warning in the POD to reuse interps and not fork. Maybe the Windows emulation of fork with threads does that, but on Linux, it's the exact opposite. Forking releases memory reliably, whereas threads don't. Reusing threads is a good idea though.
| [reply] |