Futex Wait Called
pandi
4.1.2. I have my user space application which communicate with my char
driver using write and read system calls. I have a thread in
application to send data to driver and concurrently a signal handler
(user space) is register. write calls is invoking continuously and
read call is also invoking continuously on notification from driver.
Here am facing a problem of "futex_wait" at one time. Even though my
user space application has no mutex locking, FUTEX_WAIT is called and
nothing proceeds after this.
I got below lines form strace of my process and always getting lock at
same address.
--- SIGRT_15 (Real-time signal 13) @ 0 (0) ---
futex(0x4aa700b0, FUTEX_WAIT, 2, NULL
please guide me to solve this issue or what could be reason for above
things.
if need any more info, i will give u.
Christof Meerwald
> I am working on fedora core 7, kernel version 2.6.21, gcc version
> 4.1.2. I have my user space application which communicate with my char
> driver using write and read system calls. I have a thread in
> application to send data to driver and concurrently a signal handler
> (user space) is register. write calls is invoking continuously and
Note that the set of functions your are allowed to use in a signal handler
is very limited (i.e. only async signal safe functions). To me it looks like
you are trying to call a non async signal safe function which causes the
problem.
Can you show use the code for the signal handler?
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
pandi
Sorry for delayed reply since i was in another work.
The code you asked is below
============================================================================
{
int i = 0, j = 0,k=0;
int bytes_rcvd;
int ret;
int file_close;
static int rcv_pkt_length =0;
unsigned long StaticStreamBuffer[4] = { 0,0,0,0 };
char fc[10];
char f2f[10] ;
int len = 0;
if(error_handler==1)
{
printf("Error handler called\n");
scanf("%c",&g);
}
gpstAppData ->s32Length = 4096;
gpstAppData ->s8CID = gConnectionInfo[0]->lCID;
gpstAppData->s8DID = gConnectionInfo[0]->lDID;
gpstAppData->s8Priority = gConnectionInfo[0]->Priority;
gpstAppData->s8F2Flag = gConnectionInfo[0]->F2Flag;
printf("Called Signal_Handler1\n");
StaticStreamBuffer[0] = gConnectionInfo[0]->lCID;
StaticStreamBuffer[1] = gConnectionInfo[0]->lDID;
ret = ioctl(gConnectionInfo[0]->filedes, UNI_GET_EVENTINFO,
StaticStreamBuffer);
if (ret < 0)
{
printf("Ioctl Failed\n");
}
gpstAppData ->s8CID = gConnectionInfo[0]->lCID;
gpstAppData->s8DID = gConnectionInfo[0]->lDID;
gpstAppData->s8Priority = gConnectionInfo[0]->Priority;
gpstAppData->s8F2Flag = gConnectionInfo[0]->F2Flag;
gpstAppData ->s32Length = StaticStreamBuffer[1] + StaticStreamBuffer
[2];
length = StaticStreamBuffer[1];
printf("Event ID = %d\n", StaticStreamBuffer[0]);
printf("Length Received = %d\n", StaticStreamBuffer[1]);
printf("OverFlow Length = %d\n", StaticStreamBuffer[2]);
bytes_rcvd = read(gConnectionInfo[0]->filedes, gpstAppData,
gpstAppData->s32Length);
fwrite(gpstAppData->aBuffer, sizeof(char), bytes_rcvd,
gConnectionInfo[0]->fWrite);
//scanf("%c",&i);
//rcv_pkt_length += bytes_rcvd;
system("> /var/log/messages");
//printf("bytes_rcvd for tc0 =%d\n", bytes_rcvd);
gConnectionInfo[0]->bytes_rcvd += bytes_rcvd;
printf("bytes_rcvd for tc0 =%d,gConnectionInfo[0]->bytes_rcvd=%d
\n",bytes_rcvd,gConnectionInfo[0]->bytes_rcvd);
if (StaticStreamBuffer[0] == 0 && (gConnectionInfo[0]->bytes_rcvd ==
gpstAppData->s32Length))
{
printf("Iteration=%d,last descriptor\n", iter);
rcv_pkt_length = 0;
gConnectionInfo[0]->bytes_rcvd = 0;
printf("test........................\n");
/*************************************/
file_close = fclose(gConnectionInfo[0]->fWrite);
if (!file_close)
{
printf("Tc0 - file closed successfully\n");
printf(" file transferred = %d\n", file_no_tc0);
}
else
{
printf("Failed to close the file handle\n");
}
gConnectionInfo[0]->fWrite = NULL;
#if 1
if (Compare())
{
printf("Test1\n");
fprintf(fcheck,"failed=> comparision file no =%d\n",file_no_tc0);
fclose(fcheck);
if(gpstAppData1->aBuffer!=NULL)
free(gpstAppData1->aBuffer);
if(gpstAppData->aBuffer!=NULL)
free(gpstAppData->aBuffer);
if(gpstAppData1!=NULL)
free(gpstAppData1);
if(gpstAppData!=NULL)
free(gpstAppData);
exit(0);
}
#endif
system("echo ==============after a write============== >> /home/
info.txt");
system("cat /proc/meminfo >> /home/info.txt");
file_no_tc0 = file_no_tc0 + 1;
#if 0
if (file_no_tc0 ==43)
{
Terminate();
while(1)
{
system("echo -e \"\\007\" >/dev/tty10 ");
sleep(1);
}
printf("terminate...............\n");
exit(0);
}
#endif
printf(" tx_file_no = %d\n", tx_file_no);
tx_file_no = tx_file_no + 1;
#if 1
if (file_no_tc0 ==43)
{
fprintf(fcheck,"passed %d sl_bl_pm=%d\n",s8Priority,sl_bl_pm);
sl_bl_pm = sl_bl_pm+2;
file_no_tc0 =1;
file_no_tc1 =1;
tx_file_no =1;
if(s8Priority ==1 && sl_bl_pm>8)
{
Terminate();
fclose(fcheck);
while(0)
{
system("echo -e \"\\007\" >/dev/tty10 ");
sleep(1);
}
printf("terminate...............\n");
exit(0);
}
else if(s8Priority ==0 && sl_bl_pm>8)
{
Terminate();
s8Priority =1;
sl_bl_pm = 2;
Establish_Connection();
}
SetBurstLengthPwrMode();
}
#endif
strcpy(gConnectionInfo[0]->rx_file, "/home/TestFiles/r\0");
strcpy(file_name, "");
sprintf(file_name, "%d", file_no_tc0);
strcat(gConnectionInfo[0]->rx_file, file_name);
printf("tc0 - gConnectionInfo[0]->rx_file=%s\n",
gConnectionInfo[0]->rx_file);
gConnectionInfo[0]->fWrite = fopen(gConnectionInfo[0]->rx_file,
"wb");
/*************************************/
//changed
receive_complete = 1;
}
printf("futex RX Checking1\n");
}
============================================================================
Thanks
pandi
On Oct 26, 11:38 pm, Christof Meerwald <NOSPAM-seeMySig
+uf...@usenet.cmeerw.org> wrote:
> On Thu, 22 Oct 2009 20:44:17 -0700 (PDT), pandi wrote:
> > I am working on fedora core 7, kernel version 2.6.21, gcc version
> > 4.1.2. I have my user space application which communicate with my char
> > driver using write and read system calls. I have a thread in
> > application to send data to driver and concurrently a signal handler
> > (user space) is register. write calls is invoking continuously and
>
> Note that the set of functions your are allowed to use in a signal handler
> is very limited (i.e. only async signal safe functions). To me it looks like
> you are trying to call a non async signal safe function which causes the
> problem.
>
> Can you show use the code for the signal handler?
>
> Christof
>
> --http://cmeerw.org sip:cmeerw at cmeerw.org
pandi
If you need any more information..please let me know...
Thanks
Christof Meerwald
> Sorry for delayed reply since i was in another work.
>
> The code you asked is below
If that's the code of the signal handler, then please have a look at
http://linux.die.net/man/2/signal for a list of async-signal-safe functions
(most of the functions you are using are not async-signal-safe).
Christof
--
pandi
any clarifications.
On Nov 26, 2:33 am, Christof Meerwald <NOSPAM-seeMySig
+uy...@usenet.cmeerw.org> wrote:
> On Tue, 24 Nov 2009 08:38:33 -0800 (PST), pandi wrote:
> > Sorry for delayed reply since i was in another work.
>
> > The code you asked is below
>
> If that's the code of the signal handler, then please have a look athttp://linux.die.net/man/2/signalfor a list of async-signal-safe functions
> (most of the functions you are using are not async-signal-safe).
>
> Christof
>
> --http://cmeerw.org sip:cmeerw at cmeerw.org
pandi
My application uses following calls that is not mentioned in link you
sent,
=================
ioctl
mmap2
ummap
fstat64
rt_sigaction
rt_sigpromask
=================
is above of any one makes my application hangs?
Please confirm since am not facing this problem periodically it is
very rare....
Thanks
On Nov 26, 12:24 pm, pandi <pandiwelco...@gmail.com> wrote:
> Ok thanks...I will go through the link and let you know if i will have
> any clarifications.
>
> On Nov 26, 2:33 am, Christof Meerwald <NOSPAM-seeMySig
>
> +uy...@usenet.cmeerw.org> wrote:
> > On Tue, 24 Nov 2009 08:38:33 -0800 (PST), pandi wrote:
> > > Sorry for delayed reply since i was in another work.
>
> > > The code you asked is below
>
> > If that's the code of the signal handler, then please have a look athttp://linux.die.net/man/2/signalfora list of async-signal-safe functions
Christof Meerwald
> My application uses following calls that is not mentioned in link you
> sent,
>=================
> ioctl
> mmap2
> ummap
> fstat64
> rt_sigaction
> rt_sigpromask
>=================
> is above of any one makes my application hangs?
What about printf, system, fwrite, fclose, ...?
> Please confirm since am not facing this problem periodically it is
> very rare....
But occasional crashes/deadlocks/... are the expected behaviour as it
depends when exactly the signal gets delivered (i.e. if some internal data
structure is left in an inconsistent state) - welcome to the world of race
conditions and undefined behaviour.
Christof
--
pandi
Many thanks for your reply for all my emails.
I got only system calls by running my application with strace ie.
(strace ./test)
Here is lines i got for my source code from the terminal window after
strace run...
================================================================
--- SIGRT_15 (Real-time signal 13) @ 0 (0) ---
write(1, "Called ReceivePkt_Handler1\n", 27Called ReceivePkt_Handler1
) = 27
ioctl(4, 0x1c, 0xbfb6e6f8) = 0
write(1, "Event ID = 0\n", 13Event ID = 0
) = 13
write(1, "Length Received = 3\n", 20Length Received = 3
) = 20
write(1, "OverFlow Length = 0\n", 20OverFlow Length = 0
) = 20
read(4, "\0\1\1", 3) = 3
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f07000
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_15], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfb6e6b4) = 3659
waitpid(3659, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3659
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RT_15], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
write(1, "bytes_rcvd for tc0 =3,gConnectio"..., 55bytes_rcvd for tc0
=3,gConnectionInfo[0]->bytes_rcvd=3
) = 55
write(1, "Iteration=1,last descriptor\n", 28Iteration=1,last
descriptor
) = 28
write(1, "test........................\n",
29test........................
) = 29
write(5, "ABC", 3) = 3
close(5) = 0
munmap(0xb7f07000, 4096) = 0
write(1, "Tc0 - file closed successfully\n", 31Tc0 - file closed
successfully
) = 31
write(1, " file transferred = 2\n", 22 file transferred = 2
) = 22
write(1, "file_no_tc0=2\n", 14file_no_tc0=2
) = 14
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_15], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfb6e684) = 3660
waitpid(3660, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3660
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RT_15], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
write(1, "3b passed\n", 103b passed
) = 10
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_15], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfb6e684) = 3661
waitpid(3661, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3661
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RT_15], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_15], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfb6e6b4) = 3662
waitpid(3662, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3662
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RT_15], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_15], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfb6e6b4) = 3663
waitpid(3663, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3663
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RT_15], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
write(1, " tx_file_no = 2\n", 16 tx_file_no = 2
) = 16
write(1, "tc0 - gConnectionInfo[0]->rx_fil"..., 53tc0 - gConnectionInfo
[0]->rx_file=/home/TestFiles/r3
) = 53
open("/home/TestFiles/r3", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
write(1, "futex RX Checking1\n", 19futex RX Checking1
) = 19
sigreturn() = ? (mask now [])
=====================================================================
I think, fopen,fwrite,system are mapped to open, mmap and any of above
strace calls.
Please suggest me. will fwrite, fopen, system gives problem?
Thanks,
pandi
On Nov 28, 2:30 am, Christof Meerwald <NOSPAM-seeMySig
+up...@usenet.cmeerw.org> wrote:
> On Thu, 26 Nov 2009 01:09:16 -0800 (PST), pandi wrote:
> > My application uses following calls that is not mentioned in link you
> > sent,
> >=================
> > ioctl
> > mmap2
> > ummap
> > fstat64
> > rt_sigaction
> > rt_sigpromask
> >=================
> > is above of any one makes my application hangs?
>
> What about printf, system, fwrite, fclose, ...?
>
> > Please confirm since am not facing this problem periodically it is
> > very rare....
>
> But occasional crashes/deadlocks/... are the expected behaviour as it
> depends when exactly the signal gets delivered (i.e. if some internal data
> structure is left in an inconsistent state) - welcome to the world of race
> conditions and undefined behaviour.
>
> Christof
>
> --http://cmeerw.org sip:cmeerw at cmeerw.org
David Schwartz
> I think, fopen,fwrite,system are mapped to open, mmap and any of above
> strace calls.
>
> Please suggest me. will fwrite, fopen, system gives problem?
>
> Thanks,
> pandi
Yes, those calls are absolutely, definitely fatal in a signal handler.
They manipulate data structures that may be in an inconsistent state
when the signal arrives.
You should rearchitect your code. One way to fix it is to just set a
flag in the signal handler, then have your main code check the flag
and do whatever needs to be done. Another way is to have a dedicated
thread whose sole purpose is to wait for signals and handle them
synchronously.
But doing "real work" in an asynchronous signal handler that
interrupts arbitrary code is *very* bad.
DS
pandi
you give me a examples/web link describes that thread receiving a
signal from kernel modules and wait for the signal from kernel
modules.
Thanks in advance...
David Schwartz
> Hi..Thanks..I will select second option. It will be better for me if
> you give me a examples/web link describes that thread receiving a
> signal from kernel modules and wait for the signal from kernel
> modules.
The Linux man page for 'pthread_sigmask' contains an example of
exactly this. Make sure to block the signal in all threads using
either pthread_sigmask or sigaction. Then have the signal handling
thread call 'sigwait', typically in a loop.
DS
pandi
pandi
After your suggestion, I'm able to work with single thread with signal
handling. However, am creating four thread with four signal mask and
waiting for a signal notification from my kernel modules. my kernel
modules using kill_proc notify the process. Here my understanding is
that all threads has to wake up and code written such that one thread
will run based on signal number it receiving. Is this possible to wake
up particular user thread instead of all threads from kernel modules?
and also it not wake up all thread if signal sends(kill_proc) to my
process...How to handler this type cases? Do i need to do any special
steps for thsi purpose?
Thanks.
Rainer Weikusat
> After your suggestion, I'm able to work with single thread with signal
> handling. However, am creating four thread with four signal mask and
> waiting for a signal notification from my kernel modules. my kernel
> modules using kill_proc notify the process. Here my understanding is
> that all threads has to wake up and code written such that one thread
> will run based on signal number it receiving. Is this possible to wake
> up particular user thread instead of all threads from kernel
> modules?
The kernel can either send a signal to an individual thread or 'to the
process' aka 'thread group'.
David Schwartz
> After your suggestion, I'm able to work with single thread with signal
> handling.
Great.
> However, am creating four thread with four signal mask and
> waiting for a signal notification from my kernel modules. my kernel
> modules using kill_proc notify the process. Here my understanding is
> that all threads has to wake up and code written such that one thread
> will run based on signal number it receiving.
I'm not familiar with kill_proc, I would think you'd use send_sig. In
any event, it doesn't matter whether it sends it to all the threads
since the signal is blocked.
> Is this possible to wake
> up particular user thread instead of all threads from kernel modules?
Yes, but I don't recommend that. You should let the process determine
how what thread the signal goes to.
> and also it not wake up all thread if signal sends(kill_proc) to my
> process...How to handler this type cases? Do i need to do any special
> steps for thsi purpose?
Since the signal is blocked in every thread but the one you care
about, why does it matter if the signal goes to these other threads?
In any event, the default behavior of sending an asynchronous signal
to a process that has that signal blocked in every thread but one is
to send that signal to the thread in which it is not blocked.
DS
David Schwartz
It occurs to me, you should take a big step back. You picked signals
as a way for your module to communicate with your process. Now that's
giving you no end of grief because you want to handle the notification
synchronously. Well, duh. Why not use a synchronous notification
scheme?!
For example, you can have one or more threads block in a 'read' or
'ioctl'. This makes it super-easy for the kernel to unblock precisely
the correct thread. There's no issue with blocking signals, waiting
for signals, or routing them. And your kernel code doesn't have to
care about what's in the same process and what isn't.
If you want to be fancy, you can tie into the 'epoll' system to
provide high-performance synchronous notification, but that may be
overkill for your application.
But it sounds like you thought you wanted signals, asked how to make
signals work, and are now working to jam a square peg in a round hole.
Step back, and think about a round hole instead!
DS
Christof Meerwald
> It occurs to me, you should take a big step back. You picked signals
> as a way for your module to communicate with your process. Now that's
> giving you no end of grief because you want to handle the notification
> synchronously. Well, duh. Why not use a synchronous notification
> scheme?!
I fully agree - although it might be useful to point out that recent Linux
kernels (with a recent glibs) support a signalfd syscall (see
http://linux.die.net/man/2/signalfd) which provides an alternative
user-space interface for handing signals.
Christof
--
pandi
I would thank you all for your suggestions. One more information like
say here is that my kernel modules emit signals asynchronously to the
process and my process has to get this and handle this synchronously.
For different signal, my process has to do synchronous processing with
different attributes. i gone through some of man pages for
select,sigfd,poll,epoll etc. are these all will work fine for my this
case? even if signal emitting asynchronously from kernel modules, will
it handle synchronously with out missing any signal? Just Confirm my
clarification......
Thanks again for your great support.
On Dec 1, 2:32 am, Christof Meerwald <NOSPAM-seeMySig
+us...@usenet.cmeerw.org> wrote:
> On Mon, 30 Nov 2009 10:38:28 -0800 (PST), David Schwartz wrote:
> > It occurs to me, you should take a big step back. You picked signals
> > as a way for your module to communicate with your process. Now that's
> > giving you no end of grief because you want to handle the notification
> > synchronously. Well, duh. Why not use a synchronous notification
> > scheme?!
>
> I fully agree - although it might be useful to point out that recent Linux
> kernels (with a recent glibs) support a signalfd syscall (seehttp://linux.die.net/man/2/signalfd) which provides an alternative
> user-space interface for handing signals.
>
> Christof
>
> --http://cmeerw.org sip:cmeerw at cmeerw.org
pandi
process handling signal X, at the same another signal(Y) or same signal
(X) may come...in this case will select/read/poll/epoll works fine?
David Schwartz
> Also i need to have multiple signal handling...for example if my
> process handling signal X, at the same another signal(Y) or same signal
> (X) may come...in this case will select/read/poll/epoll works fine?
Absolutely. You can, for example, allow the process to open as many
file descriptors as it wants and use an 'ioctl' to signify which
events each file descriptor is associated with. It can then use
'select', 'read', 'poll' or 'epoll' (or even 'signalfd') to get the
events associated with each fd.
Going that far may be overkill for your application.
DS
pandi
>>Going that far may be overkill for your application.
what does it mean? can you please explain little bit more? will my
application destroy if it is run far?
If so, how do i solve problem? I need concrete application . It should
not crash any where at any time without user decision.
Thanks.
David Schwartz
> > Going that far may be overkill for your application.
Sorry, this was an English metaphor that is no cause for alarm.
What I mean is that you don't have to do it the very best possible
way.
DS
pandi
Thanks for explanation.
Then, what i understood that from select/poll/epoll is, my kernel
modules should have driver method for these system calls and then it
should have called "poll_wait" also. "poll_wait" uses
"wait_queue_head_t" as argument. it seems that i need to redesign my
kernel modules also...was my understanding correct? ...if i will have
to redesign kernel modules for these utilities, It would be better to
go any other option without redesign my kernel module. As per my
kernel module design, it just emit signal, that's all. Then my process
has to catch the signal and do particular signal handling. are these
possible?
If no, What you do u think on using any one below option as you said
before?
"One way to fix it is to just set a
flag in the signal handler, then have your main code check the flag
and do whatever needs to be done. Another way is to have a dedicated
thread whose sole purpose is to wait for signals and handle them
synchronously. "
But here multiple thread for a single signal handling is not working
correctly..we need to analyze this one or go for first option.
One more option we have is one or more thread block in read or ioctl
call. what do u think on this also?
Thanks in advance.
David Schwartz
> Then, what i understood that from select/poll/epoll is, my kernel
> modules should have driver method for these system calls and then it
> should have called "poll_wait" also. "poll_wait" uses
> "wait_queue_head_t" as argument. it seems that i need to redesign my
> kernel modules also...was my understanding correct? ...if i will have
> to redesign kernel modules for these utilities, It would be better to
> go any other option without redesign my kernel module. As per my
> kernel module design, it just emit signal, that's all. Then my process
> has to catch the signal and do particular signal handling. are these
> possible?
Yes, it's possible. If it's too hard to revisit a bad decision, you
may be stuck with it. I'm curious how this came to be chosen though.
Other kernel modules don't work this way.
> If no, What you do u think on using any one below option as you said
> before?
>
> "One way to fix it is to just set a
> flag in the signal handler, then have your main code check the flag
> and do whatever needs to be done. Another way is to have a dedicated
> thread whose sole purpose is to wait for signals and handle them
> synchronously. "
>
> But here multiple thread for a single signal handling is not working
> correctly..we need to analyze this one or go for first option.
That's the problem with signals. They play badly with threads.
Signals are really only useful for a few special cases. Synchronous
signals (like SIGILL, SEGSEGV) are useful for handling error
conditions and abnormally terminating a program. Communication signals
(SIGINT, SIGUSR1) are useful for crude inter-process communication.
But signals are not a good communication or notification scheme when
additional data is involved or cooperating with other schemes is
needed.
> One more option we have is one or more thread block in read or ioctl
> call. what do u think on this also?
So long as the maximum number of threads that might be needed, this is
tolerable. There's a performance hit due to the extra context switches
required. If you're talking about two or three threads, that's fine.
In a worst case scenario, you will wind up with one wasted context
switch per signal sent. (If you can make one signal notify of more
than one thing, that can help with this.)
DS
pandi
> Yes, it's possible. If it's too hard to revisit a bad decision, you
> may be stuck with it. I'm curious how this came to be chosen though.
> Other kernel modules don't work this way.
How is this possible? by what method i have to get this to be done and
could you please show the direction to that way?
Synchronous signal handling is ultimate target. We had several option
to do this as per you all suggestion.
I was not aware of these all thing, how and where to be used. After
turning some web page on this only i came to know these are all used
for these purpose under some constraints.
After getting your points,i will decide the way to go.
Thanks.
Rainer Weikusat
> On Dec 3, 4:05�am, pandi <pandiwelco...@gmail.com> wrote:
[...]
>> "One way to fix it is to just set a
>> flag in the signal handler, then have your main code check the flag
>> and do whatever needs to be done. Another way is to have a dedicated
>> thread whose sole purpose is to wait for signals and handle them
>> synchronously. "
>>
>> But here multiple thread for a single signal handling is not working
>> correctly..we need to analyze this one or go for first option.
>
> That's the problem with signals. They play badly with threads.
Not at all. 'Signals' (like threads) play bad with people who (for
some reason I don't understand) have no concept of 'multiple
independent things in motion' (I would really love to have a better
term for that, because this is just my mental metaphor). But that's
not a problem of signals, just a problem of those people (it is
arguably a problem of signals in Linux, because some of these people
to 'realtime kernel programming' ...).
> Signals are really only useful for a few special cases. Synchronous
> signals (like SIGILL, SEGSEGV) are useful for handling error
> conditions and abnormally terminating a program. Communication signals
> (SIGINT, SIGUSR1) are useful for crude inter-process communication.
> But signals are not a good communication or notification scheme when
> additional data is involved
As long as the amount of data is small, ie, an integer or a pointer,
it can be attached to so-called 'realtime signals'. Signal driven I/O
is also quite useful.