[Lazarus] HTTP client/server components committed.

[Michael Schnell]

On 05/17/2011 11:32 AM, michael.vancanneyt at wisa.be wrote:
> That's just name picking.  Polling = asking a question.
OK, to be clear we should use "busy polling" (according to a  "busy 
loop" or spinlock).

But even not busy polling (that avoids performance killing for other 
threads and processes) is only appropriate, if all possible main thread 
events from all possible sources immediately take the main thread out of 
the loop, so that no unnecessary latency is introduced to any of them.

> From the point of view of the application, it is polling the kernel 
> for availability of data: the call returns as soon as there is data ...

Hmm.... As I see it, from the view of the application it is a function 
call that returns as soon as one of the attached events is scheduled by 
whomever. But supposedly this is exactly the same.
>
> So there is no 'event' involved at the application level, just a call 
> to the
> kernel.

For me "there is data" is exactly the same as an "Event". If this "data" 
is generated by a thread (and then transferred to the Kernel <e.g. 
using a semaphore or a pipe> ), for me, this is an "Event at application 
level".

An obvious Linux implementation for application events (such as 
necessary for TThread.Synchronize and Application.QueueAsycCall) could 
be using epoll() (as you already mentioned). epoll() could monitor one 
or more pipes. Another way would be to use a single semaphore 
(supposedly best done by pthread_mutex_...() calls) that manages the 
waiting on any events to be pushed to an event queue implemented in Pascal.

> What you describe as 'polling' is the crudest form of user-land polling,
> which is of course very CPU intensive and to be avoided at all costs.
I was mistaken that you meant exactly this by the term of "polling", as 
I did not know the meaning of the term you obviously were thinking of.

-Michael