[FFmpeg-devel] libossupport status

[Vadim Lebedev]

Michael Niedermayer wrote:

>On Sat, Dec 22, 2007 at 10:18:41PM +0100, Vadim Lebedev wrote:
>  
>
>>Michael Niedermayer wrote:
>>
>>    
>>
>>>On Sat, Dec 22, 2007 at 08:06:51PM +0100, Vadim Lebedev wrote:
>>> 
>>>
>>>      
>>>
>>>>Luca Abeni wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi all,
>>>>>
>>>>>int the last weeks, I've been silent about libossupport, but I continued
>>>>>to work on it. Here is a report about the current status of things.
>>>>>
>>>>>First of all, the requirements:
>>>>>1) Eliminate all the OS-dependent code from libav* (this can be achieved
>>>>>in small steps)
>>>>>2) For standard (POSIX?) systems, no dependency on libossupport should
>>>>>be created
>>>>>3) libav* code should use standard (POSIX?) functions, and the
>>>>>implementation of such functions for non-standard systems should be
>>>>>provided by libossupport
>>>>>4) It seems that most of the developeres do not want libossupport in
>>>>>ffmpeg, but want it as an external library.
>>>>>
>>>>>Did I understand the requirements correctly? Am I forgetting anything?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I wonder how do you intend to implement missing POSIX functionality on 
>>>>Win32 plaftorm
>>>>   
>>>>
>>>>        
>>>>
>>>Theres no intention to implement it all, just what we need in ffmpeg.
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>For example on win32  close()  will not accepts socket handles  and 
>>>>select()  will not work on file handles, meaning
>>>>   
>>>>
>>>>        
>>>>
>>>If win32 supports closing sockets, there should be a function doing that,
>>>that can then be used. If it supports the equivalent of select() on files
>>>AND we need that, then the existing function can be used.
>>>If win32 doesnt support XYZ and we do have a implementation for it currently,
>>>that can be moved from libavformat to libossupport. If we win32 doesnt
>>>support XYZ and we do not have a implementation for it there wont be one
>>>on libossupport either. At least not until some win32 devel implements it.
>>>
>>> 
>>>
>>>      
>>>
>>I'm affraid i was not clear enough:
>>
>>Suppose that ffmpeg (or one of components) use 'close(fd)'   to close 
>>file decriptors and sockets.
>>On WIN32 it means that ossupport will have to imlement 'close' routine 
>>which takes a pseudo fd determinine if it relates to file descriptor
>>or socket descriptor and do esear call to 'original_close(realfd[fd])'  
>>or closesocket(realdsocket[fd]).
>>Now in order for this to work we need we need to implement our owne 
>>version of 'open' and 'socket' APIs.
>>And of course most of the syscalls which accepts file decritptors.
>>
>>This will pose 2 problems: 
>>1) Sheer amouht of work
>>2) public symbol clash. 
>>    It will be difficutl to have our  'close' function which will be 
>>called 'close' by the way to call original 'close' for C runtime library
>>
>>
>>The current approach with "#include "os_support.h"  avoid all these problems
>>    
>>
>
>Let me try again, libossupport is a place to move the CURRENTLY EXISTING os
>support code to. And whenever possible to clean it up in the process.
>
>For close() there are 2 possibilities.
>1. if the used file/socket descriptors are unique relative to each other
>   on windows then calling close(some socket) will fail -> closesocket()
>   can be tried this is 2 lines of code
>2. if the used file/socket descriptors are not unique relative to each other
>   on windows, that is close(5) and closesocket(5) both succeed and do
>   something else then we can just do:
>
>source in libav*:
>#include "libossupport/os_support.h"
>..
>loss_nonstd_closesocket(socket);
>
>libossupport/os_support.h:
>#if HAVE_CLOSESOCKET but not CLOSE
>#   define loss_nonstd_closesocket closesocket
>#else
>#   define loss_nonstd_closesocket close
>#endif
>
>This also does not add any dependancy on libossupport at link nor runtime.
>Not even for windows.
>
>If possible we should use POSIX and emulate that in libossupport. If this is
>not possible then non standard functions/macros can be added to libossupport
>with names making their non standard-ness clear. This ideally should be done
>so that no link/runtime dependency is added.
>
>[...]
>  
>
>  
>
I agree,
But it seems that original message in this thread suggest different 
approach:  The patch for example proposes
to remove #include "os_support.h" and
to replace:

    ff_socket_nonblock(server_fd, 1);
by:
    fcntl(server_fd, F_SETFL, fcntl(server_fd, F_GETFL) | O_NONBLOCK);



This will no work on win32 (there is no F_SETFL on WIN32)

The best way IMO will be to keep evrywhere

#include "os_support.h" 

and have functions like 'ff_socket_nonblock' defined in os_support.h as 
macros or noops
this way there will be no runtime and linktime deps on most platforms

Thanks
Vadim

>------------------------------------------------------------------------
>
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel at mplayerhq.hu
>http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>