siginfo_t missing member si_band

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

siginfo_t missing member si_band

Ryan Johnson-10
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?
Ryan


--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Christopher Faylor-8
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.

--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Ryan Johnson-10
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.

Ryan


--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Christopher Faylor-8
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.

cgf

--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Larry Hall (Cygwin)
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Warren Young
On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)

Well, it *is* a standard.  RFC 2324: http://tools.ietf.org/html/rfc2324

--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Corinna Vinschen-2
On Oct 15 17:16, Warren Young wrote:
> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> >Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>
> Well, it *is* a standard.  RFC 2324: http://tools.ietf.org/html/rfc2324

I'd expect there's an OSS library somewhere around which implements it.
Or maybe we could just grab the BSD code...


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Bengt Larsson-4
In reply to this post by Christopher Faylor-8
Christopher Faylor wrote:

>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.

Is a bug report "requestware"? I actually did look at the malloc code
but I found it very hard to understand.

--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Corinna Vinschen-2
On Oct 16 15:17, Bengt Larsson wrote:
> Christopher Faylor wrote:
>
> >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.
>
> Is a bug report "requestware"? I actually did look at the malloc code
> but I found it very hard to understand.

No, good bugreports with testcases are usually a joy (unless it's in a
part of code the developer hates a lot, but that goes without saying, I
guess).  As for the Doug Lea malloc code, I think there aren't so many
people claiming they fully understand the code.  Except Doug Lea,
probably.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Christopher Faylor-8
In reply to this post by Corinna Vinschen-2
On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
>On Oct 15 17:16, Warren Young wrote:
>> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
>> >Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>>
>> Well, it *is* a standard.  RFC 2324: http://tools.ietf.org/html/rfc2324
>
>I'd expect there's an OSS library somewhere around which implements it.
>Or maybe we could just grab the BSD code...

I don't see how SIGPOLL could be implemented by copying BSD code.  It
would have to rely on modifying the fhandler code.

--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Ryan Johnson-10
On 16/10/2013 5:27 PM, Christopher Faylor wrote:
> On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
>> On Oct 15 17:16, Warren Young wrote:
>>> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
>>>> Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>>> Well, it *is* a standard.  RFC 2324: http://tools.ietf.org/html/rfc2324
>> I'd expect there's an OSS library somewhere around which implements it.
>> Or maybe we could just grab the BSD code...
> I don't see how SIGPOLL could be implemented by copying BSD code.  It
> would have to rely on modifying the fhandler code.
It would be fascinating to see the patch that teaches fhandler to make
coffee...

(BTW, that's neither a request nor a wish. Cygwin isn't requestware or
wishware.)


--
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

Reply | Threaded
Open this post in threaded view
|

Re: siginfo_t missing member si_band

Corinna Vinschen-2
On Oct 16 23:46, Ryan Johnson wrote:

> On 16/10/2013 5:27 PM, Christopher Faylor wrote:
> >On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
> >>On Oct 15 17:16, Warren Young wrote:
> >>>On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> >>>>Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
> >>>Well, it *is* a standard.  RFC 2324: http://tools.ietf.org/html/rfc2324
> >>I'd expect there's an OSS library somewhere around which implements it.
> >>Or maybe we could just grab the BSD code...
> >I don't see how SIGPOLL could be implemented by copying BSD code.  It
> >would have to rely on modifying the fhandler code.
> It would be fascinating to see the patch that teaches fhandler to
> make coffee...
>
> (BTW, that's neither a request nor a wish. Cygwin isn't requestware
> or wishware.)
And, unfortunately, it's not even coffeeware.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (853 bytes) Download Attachment