|
Home > Archive > Unix Programming > November 2004 > Is this a poll() bug on solaris?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is this a poll() bug on solaris?
|
|
| Harley Wang 2004-11-03, 2:48 am |
|
Hi,
I met a problem when using poll() on solaris 2.8. The scenario is below,
There are two threads A and B in program. Every thread own some file desc
(struct pollfd poll_info[]) need to poll.
Now A is runing into poll() and waiting for any event on those file desc. Note:
Before A runs into poll(), it has reset its poll_info[].events.
At this time, B was signaled from poll(), and handle the event of its own
pollfds. Sometime B need to change A's poll_info[], then send signal to A's
poll_info[] to wake up A.
Then A is wakeup from poll(). But I found the changes did during A is sleeping
is lost. It seems solaris is rewrite A's poll_info[] with the data before A ran
into poll().
I didn't test select(), not sure if select() has same problem.
Is this known bug on solaris? Or this is normal behavior of solaris?
Thanks in advance!
Harley
| |
| Casper H.S. Dik 2004-11-03, 2:48 am |
| Harley Wang <huawang@lucent.com> writes:
>At this time, B was signaled from poll(), and handle the event of its own
>pollfds. Sometime B need to change A's poll_info[], then send signal to A's
>poll_info[] to wake up A.
>Then A is wakeup from poll(). But I found the changes did during A is sleeping
>is lost. It seems solaris is rewrite A's poll_info[] with the data before A ran
>into poll().
The poll_info[] data is owned by the kernel while A is blocked in
a system call; the kernel copies in the poll array on entry to poll
and copies it back out on exit. You can't modify data in use
by another thread; so you need to find some other mechanism to
do so.
(For the kernel, it's much cheaper to copy the entire array back out then
to copy only the revents bits for all the parts of the poll structure)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| David Schwartz 2004-11-03, 2:48 am |
|
"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
news:4188965f$0$559$e4fe514c@news.xs4all.nl...
> The poll_info[] data is owned by the kernel while A is blocked in
> a system call; the kernel copies in the poll array on entry to poll
> and copies it back out on exit. You can't modify data in use
> by another thread; so you need to find some other mechanism to
> do so.
A common method is to call 'poll' as follows:
1) Acquire a mutex
2) Copy the master poll set
3) Release the mutex
4) Call poll on the copy
5) When poll returns, look at the copy to see what I/O to do
Modify the poll set as follows:
1) Acquire the same mutex used above
2) Modify the master poll set
3) Release the mutex.
This ensures that the modification is not done while the first thread is
accessing the poll set but also allows the modification to occur during the
call to 'poll'.
DS
| |
| Harley Wang 2004-11-05, 2:47 am |
|
Casper,
Right. Thanks a lot for your help. That's I want to know. :-)
Best regards,
Harley
"Casper H.S. Dik" wrote:
>
> Harley Wang <huawang@lucent.com> writes:
>
>
>
> The poll_info[] data is owned by the kernel while A is blocked in
> a system call; the kernel copies in the poll array on entry to poll
> and copies it back out on exit. You can't modify data in use
> by another thread; so you need to find some other mechanism to
> do so.
>
> (For the kernel, it's much cheaper to copy the entire array back out then
> to copy only the revents bits for all the parts of the poll structure)
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
| |
| Harley Wang 2004-11-05, 2:47 am |
|
All,
Thanks a lot for your help!
I did some changes in my code: added another copy for poll_info, also, I put a
lock for it. It works normally. Now I can catch all events.
Scenario:
Here we have two copies about poll_info1, poll_info2. Lock is not ignored here,
the only thing need to know is, poll_infos will be unlocked during call poll().
1). Copy poll_info1 to poll_info2,
2). Call poll() on poll_info2.
3). after return form poll(), according to revents from poll_info2, update
poll_info1's fd, events and revents, and do what I want to do.
4). Go back to 1).
Thanks,
Harley
David Schwartz wrote:
> A common method is to call 'poll' as follows:
>
> 1) Acquire a mutex
> 2) Copy the master poll set
> 3) Release the mutex
> 4) Call poll on the copy
> 5) When poll returns, look at the copy to see what I/O to do
>
> Modify the poll set as follows:
>
> 1) Acquire the same mutex used above
> 2) Modify the master poll set
> 3) Release the mutex.
>
> This ensures that the modification is not done while the first thread is
> accessing the poll set but also allows the modification to occur during the
> call to 'poll'.
>
> DS
|
|
|
|
|