[fpc-pascal]Synapse for FPC

Marco van de Voort marcov at stack.nl
Wed Jul 23 14:59:05 CEST 2003


> 
> > Hmm, I think this is more due to the move to event driven programming
> models
> > than cooperative multitasking.
> 
> No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
> without threads?

Yes.

> It will block untill it receives the response. This completely* stops the
> *flow of the application, be it DOS, WinAPI, VCL, or
> some exotic home brew GUI toolkit.

But under Dos you would do simple polling, since the eventloop of your own.
The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision,
but the eventloop is under your control)

E.g.

repeat
  a:=select(...);   //block but maximal n msec.
  if (a) Then		// if a not timed out
   Event:=TranslateTCPIPEvent(A)
  else
   Event:=PollEventKeyBoardMouse();
  If Event=filled Then
    Dispatchevent(Event);
  {$ifdef Win31}
   ProcessMessages():
  {$endif}
until Event=quit;  

While with most other OSes/toolkits the OS/toolkit has the eventloop, and
you only provide callbacks and msghooks.
  
> Now consider M$ Windows 3.1. It had no threaded capability and only very
> crude methods for yielding to other processes. This is the reason that M$
> opted for non-blocking api, and the fact that it eased the event driven
> model was a bonus rather than a goal.

But TCP/IP and blocking/non-blocking existed before Windows (and probably
will exist after). Maybe win3.1 that had some effect on the Windows api,
but not on TCP/IP as a whole.

> If your app on Win3.1 didn't yield to other processes, you locked Windows.

This means that your app can't be 100% blocking. However that doesn't mean
you need to have threads. You app must deblock once every second or so and
process messages/yield.





More information about the fpc-pascal mailing list