[Lazarus] HTTP client/server components committed.

[Michael Schnell]

On 05/17/2011 10:34 AM, michael.vancanneyt at wisa.be wrote:
>
> Any implementation will always use polling. You may hide it under some 
> kind
> of abstraction, but it's always polling. On unix with select() or 
> epoll(), on Windows with PeekMessage/GetMessage and friends. Your 
> Delphi windows timer uses PeekMessage/GetMessage by the message pump 
> as well. 

Sorry, but you are wrong here.

Linux: select() and epoll() don't do polling (even if the name "epoll" 
is misleading). Theses API calls make the thread sleep with zero CPU 
time until one of the appropriate events is fired (by a Kernel driver or 
another thread) and then the Kernel wakes up the thread and same is 
scheduled according its priority setting (i.e. ASAP).

So the problems of polling are avoided. (Such as latency when doing a 
slow polling e.g. by means of "sleep()", and high performance overhead 
when doing fast polling).

With the GUI based Widget Types, the zero-overhead waiting is performed 
by the external GUI framework which is called by the user program after 
any main thread event is handled. Here the additional problem is, that 
the GUI generated events and the thread generated events need to be 
merged. With Windows, this is done by the System as the thread will 
generate an event as a a Windows Message so that the main thread is 
waked up and can receive the message with PeekMessage/GetMessage. This 
is not polling, as the GUI framework call returns only if some message 
is received. AFAIK, in Linux this merging is more complicated.

But with FPGui and the possible Widget Type discussed here, there are no 
GUI Framework events, and so e.g. epoll() can be used to do a 
zero-overhead latency free waiting for all possible events. (I suppose 
Graeme did his implementation similar to this.)

-Michael