is it ok to receive SIGIO in the same context calling SG code?

is it ok to receive SIGIO in the same context calling SG code?

[William Chow]

The documentation associated with the UNH target
emulator project indicates that the thread which
receives the SIGIO cannot also be the context which
calls SG, e.g. for submitting the async I/O. It states
that "there are certain sections of the SCSI generic
code that do not expect to receive signals". Does
anyone have any information, implementational or even
empirical, that would confirm/refute this?

Thanks for any assistance.

ps: please CC me directly in the response.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: is it ok to receive SIGIO in the same context calling SG code?

[Douglas Gilbert]

William Chow wrote:
> The documentation associated with the UNH target
> emulator project indicates that the thread which
> receives the SIGIO cannot also be the context which
> calls SG, e.g. for submitting the async I/O. It states
> that "there are certain sections of the SCSI generic
> code that do not expect to receive signals". Does
> anyone have any information, implementational or even
> empirical, that would confirm/refute this?

William,
Well I found the reference but I'm not sure exactly what
was meant by that. The reference was dated 2001 so things
may have improved since then (but I do not remember addressing
any problem in that area).

In a followup post to me you asked about async completion
callbacks. After looking at Jonathan Corbet's article about
async I/O in the lk 2.5 series, it should be relatively
simple to add a aio_write() entry point in sg. It would
have the same semantics as sg's normal write(). When the
response to the command is received the associated
aio_complete() could be called. The SCSI status byte could
even be placed in 'res2'.


[Aside: the SG_IO ioctl is synchronous. The asynchronous
interface offered by the sg driver (via write()/read())
does have its uses (and users).]

Doug Gilbert