Cancel read on socket

[Wolfram Wadepohl]

Ralf Corsepius schrieb:

> On Wed, 2008-05-28 at 15:23 +0200, Wolfram Wadepohl wrote:
> 
>>Leon Pollak schrieb:
>>
>>>Here is the good point.
>>>And I should not speak about this, if there was no precedent - CancelIo in 
>>>Windows. Yes, I don't like MS at all, but they did it much later then 
>>>Berkley/BSD - still may be they already saw this need...:-)
>>>
>>>And besides, BSD stack was designed mostly not for RT applications where 
>>>requirements are not so hard... IMHO...
>>
>>I 've also missed a CANCEL function for a blocking read from termios.
>>
>>also see http://rtems.rtems.org/pipermail/rtems-users/2007-May/001031.html 
>>from Eric.
>>
>>IMHO RTEMS is much nearer to VxWorks than to BSD.
> 
> This is not a matter of imitating proprietary APIs, and converting RTEMS
> into an VxWorks imitation cult, this about IEEE/ISO/POSIX-compliant APIs
> and standards.
Really not. IEEE/ISO/POSIX and other standards are compromises to fit most
but not all types of application. BSD sockets are not targeted to real time
systems but (and only for example) VxWorks and other RTOSes. Please don't
forget the RT aspect.
> 
> 
>> I would like to see a 
>>generic CANCEL for all blocking reads terminal and network.

> /me wonders how most other OSes could get away without it?
sorry me not, because also most of these Oses don't support my application

> That said, I think you are having an application design problem.

Or having choosen the wrong operating system for the applications need.
Remember that most of the realtime applications still use proprietary or no
RTOS at all.

Following the list for a time, i get the impression that the development is
not driven by application but by bureaucracy.

It is not even allowed to discuss technical matters to support specific
applications. That's not the way the community should work. I'm indeed very
disappointed. Under this circumstances i have to reconsider the
decision-making for RTEMS.

Sorry for the harsh posting, but this actually reflect my mood.


Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3701 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.rtems.org/pipermail/users/attachments/20080528/376e515a/attachment.bin>