From: XComp <xcomp@arcor.de>
To: linux-c-programming@vger.kernel.org
Subject: Problem with ucontext_t struct in signal handler
Date: Thu, 18 Dec 2008 10:11:59 -0800 [thread overview]
Message-ID: <0C323BC7-E8EF-4CFB-99AE-9A7A890A6191@arcor.de> (raw)
Hello everyone,
I want to switch between user contexts using a signal handler
(something like a preemptive scheduler for userlevel threads). I've
found several sources, which say that it's not a good idea to use
setcontext or swapcontext in a signal handler. Nevertheless there also
exists at least one sample code of such an preemptive scheduler, which
seems to work well, at least on my machine (Ubuntu 8.04 with linux
kernel 2.6.24-22): www.seas.upenn.edu/~cse381/context_demo.c
// [...]
static ucontext_t thread_context;
static ucontext_t scheduler_context;
int thread_finished;
int i;
static void simple_function(void) {
// do nothing but counting
for (i = 0; i < 1000000000; ++i) { }
if (i == 1000000000) {
printf("\n[Thread Function]\t1st counting worked fine...");
} else {
printf("\n[Thread Function]\tError: Counting didn't finished
(%d)...", i);
}
thread_finished = 1;
}
static void other_function() {
// thread_finished is a global variable, which is set to 1, if the
thread function is finished
while(thread_finished != 1) { swapcontext(&scheduler_context,
&thread_context); }
}
static void signal_handler_function(int sig_nr, siginfo_t* info, void
*old_context) {
if (sig_nr == SIGPROF) {
// saves the thread context
thread_context = *((ucontext_t*) context);
// swaps back to scheduler context
setcontext(&scheduler_context);
}
}
// [...]
I ran into the following problem which belongs to the code above. I
interrupted simple_function several times by using a ITimer. But the
for-loop doesn't finish successfully everytime. Often the if condition
is false. But it does not cancel after the first signal is raised.
I've found out that using the third parameter old_context for storing
the old context is the reason. But I don't know why. So I thought
there might be a problem in the kernel. Am I right? I was afraid to
post the whole code, so I hope that this code snippet is enough.
I would appreciate if someone can give me a comment whether this
strange behaviour is because of a wrong thinking of mine or because of
a error in the kernel which needs to be fixed.
Thanks a lot!
Matthias
next reply other threads:[~2008-12-18 18:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 18:11 XComp [this message]
2008-12-19 2:51 ` Problem with ucontext_t struct in signal handler Glynn Clements
-- strict thread matches above, loose matches on Subject: below --
2008-12-19 7:29 XComp
2008-12-19 12:22 ` Glynn Clements
2008-12-22 17:31 ` XComp
2008-12-22 23:01 ` Glynn Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0C323BC7-E8EF-4CFB-99AE-9A7A890A6191@arcor.de \
--to=xcomp@arcor.de \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).