Prev: How can I determine the current default/working directory?
Next: mk-configure - lightweight replacement for autotools
From: Thomas Maier-Komor on 27 Dec 2009 09:44
On 27.12.09 15:42, J de Boyne Pollard wrote:
> TMK> My question was really whether the
> TMK> standard says anything about this.
>
> And your answer is "Yes". Read what the standard says about non-
> cancelled I/O requests completing as if the close() didn't occur until
> the end of the I/O request.

Thank you for the pointer.

- Thomas
From: Thomas Maier-Komor on 27 Dec 2009 09:48
On 27.12.09 15:39, Xavier Roche wrote:
> Thomas Maier-Komor a �crit :
>> what it seems to be doing is obvious. My question was really whether
>> the standard says anything about this.
>
> The standard (see the opengroup pages in my message) does not seem to
> say anything, unfortunately.
>
>> In case of Linux, changing sa_flags to 0 has no impact what so ever
>
> [ Yep, because kill() (and friends) seem to send the signal to the first
> thread. A quick solution is to mirror the signal to the correct thread
> if necessary:
>
> static pthread_t thr;
> void sig_handler(int sig)
> {
> if (sig != SIGINT)
> return;
> if (pthread_self() == thr)
> return;
> write(STDOUT_FILENO,"sig_handler\n",12);
> pthread_kill(thr, sig);
> }
> ]


Hi Xavier,

that is a good idea.

Thanks,
Thomas
From: Xavier Roche on 27 Dec 2009 09:52
>> if (pthread_self() == thr)

Just a last small note for readers: portable code should use
pthread_equal(pthread_self(), thr) instead of the == operator, for
cleaner code.
From: Rainer Weikusat on 27 Dec 2009 13:03
Thomas Maier-Komor <thomas_no_spam(a)maier-komor.de> writes:
> On 27.12.09 15:42, J de Boyne Pollard wrote:
>> TMK> My question was really whether the
>> TMK> standard says anything about this.
>>
>> And your answer is "Yes". Read what the standard says about non-
>> cancelled I/O requests completing as if the close() didn't occur until
>> the end of the I/O request.
>
> Thank you for the pointer.

When there is an outstanding cancelable asynchronous I/O
operation against fildes when close() is called, that I/O
operation may be canceled. An I/O operation that is not
canceled completes as if the close() operation had not yet
occurred. All operations that are not canceled shall complete
as if the close() blocked until the operations completed.

There is no asynchronous I/O involved in your program and hence, this
paragraph doesn't apply to it since it refers to cancelable,
asynchronous I/O operations.

From: Chris Friesen on 28 Dec 2009 00:48
On 12/27/2009 12:03 PM, Rainer Weikusat wrote:

> When there is an outstanding cancelable asynchronous I/O
> operation against fildes when close() is called, that I/O
> operation may be canceled. An I/O operation that is not
> canceled completes as if the close() operation had not yet
> occurred. All operations that are not canceled shall complete
> as if the close() blocked until the operations completed.
>
> There is no asynchronous I/O involved in your program and hence, this
> paragraph doesn't apply to it since it refers to cancelable,
> asynchronous I/O operations.

Which as far as I can tell means that the issue in the original message
is not specifically addressed in the standard.

I suspect the linux/glibc folks decided to treat a read() running on
another thread as though it were an async I/O operation.

Interesting case.

Chris
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How can I determine the current default/working directory?
Next: mk-configure - lightweight replacement for autotools