LinuxThreads question...
Daniel Seagraves
If this is not the correct group to send this to, I apologise - I'm not
sure who to ask this.
I'm coding on a MUD, and it does a DNS lookup on all connecting
players. Since the DNS lookup can be quite lengthy, certain people were
using it to launch denial-of-service attacks against the MUD. So I put
the lookup in a second thread. This works fine, so far. The problem is,
now the MUD doesn't dump core. RTFMing revealed that Linux will not dump
core if the dying program shares memory.
98% of the time (That's a figurative number, it's likely to be
higher. ^_^) the MUD is running as a single thread - It only spawns a
second thread if there's a lookup to be done. During this time (when no
threads are running) is when the MUD usually crashes. (Since several days
or even weeks can pass between crashes, putting in watchpoints and debug
printf's isn't a feasable option.) The only thing the mud shares it's
memory with (and the only thing keeping it from being able to dump
core) is the manager thread, created (as far as I can tell) after
pthread_create is called for the first time.
So the question is, is there a way to make the manager thread go away when
it's not in use? I dug through it manual pages and poked around online,
and I can't seem to find anything. Or, more likely, am I completely wrong
and should I be going about this a different way?
Again, apologies if I am annoying the wrong people with this.
Arnold Hendriks
> 98% of the time (That's a figurative number, it's likely to be
> higher. ^_^) the MUD is running as a single thread - It only spawns a
> second thread if there's a lookup to be done. During this time (when no
be easier to fork() a seperate process instead to do the DNS lookups, and
have it send back its results via a pipe() ?
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Daniel Seagraves
> If the only thing the seperate thread does is DNS resolves, wouldn't it
> be easier to fork() a seperate process instead to do the DNS lookups, and
> have it send back its results via a pipe() ?
Yes, but it gets to about 30-40 meg in size when things get busy, fork
that two or three times and you're finished performance-wise.
David Schwartz
How so? The processes doing the resolves aren't going to touch that
many pages.
DS
Daniel Seagraves
> How so? The processes doing the resolves aren't going to touch that
> many pages.
OK, I'm an idiot. I was told fork() spawned a second process that exactly
duplicated the first, but it really does it with copy-on-write pages.
The man page says exactly that; I should have read it first I guess.
Mark Johnson
> [snip]I'm coding on a MUD, and it does a DNS lookup on all connecting
> players. Since the DNS lookup can be quite lengthy, certain people were
> using it to launch denial-of-service attacks against the MUD. So I put
> the lookup in a second thread. This works fine, so far. The problem is,
> now the MUD doesn't dump core. RTFMing revealed that Linux will not dump
> core if the dying program shares memory.[snip]
If you want to run the DNS in another process context - why not have a pair
of cooperating programs [the MUD, the helper] that does the following...
- the MUD makes a DNS request [your choice of mechanism]
- the helper does the lookup and returns the answer [your choice of
mechanism]
Another person mentioned pipes as a solution. You could also use shared
memory [shmget(2)], memory mapped files [mmap(2)], signals or a variety of
other solutions. There is no reason the MUD program has to always launch a
program to do work - keep your system overhead low by having a small helper
stay resident and save the image activation costs.
If you have a start script, run the helper as a background application, wait
a moment [e.g., sleep 5] & then fire up the MUD program. That will get both
running in a consistent manner.
Good luck.
--Mark
Andrzej Popowski
<dsea...@sakura.lunar-tokyo.net> wrote:
>This works fine, so far. The problem is,
>now the MUD doesn't dump core. RTFMing revealed that Linux will not dump
>core if the dying program shares memory.
Make a signal handler for signals like SIGSEGV and put in it
pthread_kill_other_threads_np(). This will stop all threads except
that one that rised signal. Then you can abort with usable core dump.
Andrzej Popowski
David Schwartz
I fairness to you, the other process might go on to touch a lot of
pages, forcing copy-on-writes anyway. The moral of this is that you
short fork on or more resolve processes early, or fork/exec a resolve
process instead.
DS