Re: siginfo_t missing member si_band

["Larry Hall (Cygwin)" <reply-to-list-only-lh@cygwin.com>]

On 10/15/2013 6:36 PM, Christopher Faylor wrote:
> On Tue, Oct 15, 2013 at 05:13:57PM -0400, Ryan Johnson wrote:
>> On 15/10/2013 3:42 PM, Christopher Faylor wrote:
>>> On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote:
>>>> Hi all,
>>>>
>>>> While trying to build python3 for cygwin, I kept encountering the
>>>> following error message:
>>>>
>>>> ./Modules/signalmodule.c: In function ?fill_siginfo?:
>>>> ./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named
>>>> ?si_band?
>>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>>> ^
>>>> Include/tupleobject.h:62:75: note: in definition of macro
>>>> ?PyTuple_SET_ITEM?
>>>> #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
>>>> = v)
>>>> ^
>>>> ./Modules/signalmodule.c:745:5: note: in expansion of macro
>>>> ?PyStructSequence_SET_ITEM?
>>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>>>
>>>> As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
>>>> and required for proper handling of SIGPOLL. The latter seems to
>>>> correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
>>>> support async I/O, but shouldn't the struct member at least exist, to
>>>> avoid breaking code that assumes its existence? The alternative is to
>>>> patch python3 locally so its os.sigwaitinfo function no longer touches
>>>> si_band, or to file a bug upstream so that the module's configury tests
>>>> for its existence before using it.
>>>>
>>>> Thoughts?
>>> Sure.  I question the utility of lying in a structure about the
>>> availability of an unimplemented feature.  If something is specifically
>>> expecting the structure member to exist it seems like it would be
>>> expecting it to do something.
>> So that would be a vote for filing a bug upstream with python's FFI
>> interface to signal handling? Fair enough.
>
> I guess so.  In a project that wasn't requestware or wishware it would
> be a spur for someone to submit code to Cygwin to implement SIGPOLL and
> it's accompanying siginfo_t handling.  Unfortunately, Cygwin seems to
> be mainly requestware these days.

Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple