summaryrefslogtreecommitdiff
path: root/src/lib/ecore_con/efl_net_socket_windows.eo (follow)
AgeCommit message (Collapse)Author
2019-03-20docs: Remove obsolete @since tags from EO filesXavi Artigas
Summary: All legacy @since tags have already moved to the *.legacy.h files. EO files are now devoid of @since tags (except some eldbus still needed for legacy). Upcoming patches will add @since 1.22 to those APIs which come out of beta in this release. APIs marked @beta do not need @since tags. Test Plan: Everything builds, EO docs (like DocFX) have no Since tags. Reviewers: zmike, bu5hm4n, lauromoura, cedric Reviewed By: cedric Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8430
2019-02-14Mark BETA classes individuallyXavi Artigas
Summary: Instead of surrounding all the #include "*.eo.h" lines in Efl.h with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark all classes as @beta in the eo files. This will allow taking them out of beta one by one as we deem them stable enough. Otherwise, the current procedure involves moving the #include line out of the ifdef block, which is cumbersome and messes include order. Depends on D7950 Fixes T7692 Test Plan: Nothing changes Reviewers: zmike, bu5hm4n, cedric Subscribers: #reviewers, #committers Tags: #efl Maniphest Tasks: T7692 Differential Revision: https://phab.enlightenment.org/D7951
2019-01-18efl: convert all classes to the new eolian syntaxMarcel Hollerbach
ref T7459 Reviewed-by: Daniel Kolesa <daniel@octaforge.org> Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es> Differential Revision: https://phab.enlightenment.org/D7684
2018-05-01ecore: move close_on_destructor to close_on_invalidate as that describe the ↵Cedric BAIL
behavior best. Fix all use to correctly behave on invalidate.
2018-04-24Efl.Net.Socket_* (from Efl.Net.Socket.*)Xavi Artigas
Ref https://phab.enlightenment.org/T6847 Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
2018-04-24Efl.Loop_* (from Efl.Loop.*)Xavi Artigas
Ref https://phab.enlightenment.org/T6847 Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
2017-12-13ecore: rename Efl.Loop_User to Efl.Loop.Consumer.Cedric BAIL
2017-03-29implement efl_net_{socket,dialer,server}_windowsGustavo Sverzut Barbieri
This is the local socket for windows, analogous to AF_UNIX. `Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and `WriteFile()` using overlapped I/O, as well as the close procedure (`FlushFileBuffers()`, `DisconnectNamedPipe()` and `CloseHandle()`). These are done on top of an existing HANDLE that is set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or `Efl_Net_Server_Windows` (from `CreateNamedPipe()`). The overlapped I/O will return immediately, either with operation completed or `ERROR_IO_PENDING`, which means the kernel will execute that asynchronously and will later `SetEvent(overlapped.hEvent)` which is an event we wait on our main loop. That `overlapped` handle must exist during the call lifetime, thus cannot be bound to `pd`, as we may call `CancelIo()` but there is no guarantee the memory won't be touched, in that case we keep the overlapped around, but without an associated object. Windows provides no notification "can read without blocking" or non-blocking calls that returns partial data. The way to go is to use these overlapped I/O, with an initial `ReadFile()` to an internal buffer, once that operation finishes, we callback the user to says there is something to read (`efl_io_reader_can_read_set()`) and wait until `efl_io_reader_read()` is called to consume the available data, then `ReadFile()` is called again to read more data to the same internal buffer. Likewise, there is no "can write without blocking" or non-blocking calls that sends only partial data. The way to go is to get user bytes in `efl_io_writer_write()` and copy them in an internal buffer, then call `WriteFile()` on that and inform the user nothing else can be written until that operation completes (`efl_io_writer_can_write_set()`). This is cumbersome since we say we "sent" stuff when we actually didn't, it's still in our internal buffer (`pd->send.bytes`), but nonetheless the kernel and the other peer may be adding even more buffers, in this case we need to do a best effort to get it delivery. A particular case is troublesome: `write() -> close()`, this may result in `WriteFile()` pending, in this case we wait using `GetOverlappedResult()`, *this is nasty and may block*, but it's the only way I see to cope with such common use case. Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()` will be canceled using `CancelIo()`. Q: Why no I/O Completion Port (IOCP) was used? Why no CreateThreadpoolIo()? These perform much better! A: These will call back from secondary threads, but in EFL we must report back to the user in order to process incoming data or get more data to send. That is, we serialize everything to the main thread, making it impossible to use the benefits of IOCP and similar such as CreateThreadpoolIo(). Since we'd need to wakeup the main thread anyways, using `OVERLAPPED.hEvent` with `ecore_main_win32_handler_add()` does the job as we expect. Thanks to Vincent Torri (vtorri) for his help getting this code done with an example on how to do the NamedPipe handling on Windows.