[twsocket] Re: ICS and FPC (Free Pascal)

Francois PIETTE francois.piette@pophost.eunet.be
Wed, 14 Jun 2000 21:01:27 +0200


> Does windows sends the signal that data is available(?)

Yes, it does by posting a message FD_READ in the message queue (the message
queue for the thread which opened the socket). By the way, it also send a
message when connected and when data can be written to the send buffer (see
all FD_xxxx messages in TWSocket source code).

> Does ICS need windows generated messages as events, or only
> messagequeus for interthread communication?

Not sure I fully understand the question. ICS is single threaded so it
doesn't use interthread communication (altough you can write a multithreaded
application using ICS. Several samples are provided).

ICS use messages to delay some operations outside of the current event
handler. See for example CloseDelayed method: it post a message to the queue
then exit. Later when current message (current event) is finished, this
message will be retrieved out of the queue and processed. Processing will
close TWSocket.

> This could be emulated by an extra thread (a signal handler-only thread
> that only checks the sockets, and then signals the other threads), but
that
> is only speculation.

I think it could be emultaed like that. This is how I plan to port TWSocket
to Kylix if Kylix doesn't support messaging like windows. The problem I see
is how to make code executed in the context of the main thread while it has
been triggered from a worker thread and without interrupting main thread
(that is wait until main thread has nothing more to do). With messages, an
event handler is never interrupted by another event because messages are not
retrived from message queue while a message is being processed.

--
francois.piette@swing.be
http://users.swing.be/francois.piette/indexuk.htm



----- Original Message -----
From: Marco van de Voort <marcov@stack.nl>
To: Francois PIETTE <francois.piette@pophost.eunet.be>
Sent: Tuesday, June 13, 2000 12:10 AM
Subject: Re: ICS and FPC (Free Pascal)


> > I'm busy implementing NOFORMS conditional compile to all components. I'v
e
> > already done with TWSocket (as you know) and TFtpCli (just done, not yet
> > tested carefully. EMail me if you wants current source code).
>
> I want to see something using twsocket running. Otherwise we are doing
both
> duplicate work. But if you see a chance, kill the obsolete units in uses
clauses.
>
> I'm going to be irritating in this discussion sometimes, but this is
because I
> need a very indeep understanding of the works of this system (which seems
> the only real problem, the rest are probably something about 20-50 oneline
> ifdefs for the whole of ICS)
>
> I have two targets:
> - ICS on FPC/win32
> - ICS possibility on other BSD socks targets (FreeBSD,Linux). Of course
with
> as much compatible with Win32 version as possible, except if too much
> overhead is involved. (which afaik only can be the msg system, I
understand
> most of it).
>
> The core question is:
> Does windows sends the signal that data is available(?)
>
> or more general:
>
> Does ICS need windows generated messages as events, or only
> messagequeus for interthread communication?
>
> This could be emulated by an extra thread (a signal handler-only thread
> that only checks the sockets, and then signals the other threads), but
that
> is only speculation.
>
> > > - (in most files)  (de)allocatehwnd(wndproc). What does this do?
> > > Set wndproc to be the tmessage handler?
> >
> > (de)allocatehwnd procedure will create a hidden window to have a handle
to
> > retrieve messages from message queue for the component, and assign
wndproc
> > as message handler. It also does the required stuff to be able to use a
> > method (wndproc) as a message handling function (windows doesn't know
> > anything about methods, if only knowns about callback functions).
>
> I'll check this out.
>
> > > Allocatehwnd could have the additional problem setting a method
> > > (instead of a procedure) as callback.
> >
> > This problem is solved in TWSocket: Windows see XSocketWindowProc as the
> > windows callback function. XSocketWindowProc will call wndproc method
after
> > retrieving the object reference from storage allocated in windows
tructure
> > at window creation (see SetWindowLong and getWindowLong use in TWSocket
> > source code).
>
> There already seems to be generic Tmethod support. So it seems that only
> (de)allocatehwnd (and the message system being untested in real apps)
> remains for fpc/win32.
>
> > > - Ftpcli:  abort procedure/method is unknown. Is this just a decent
> > > halt?
> >
> > In FtpCli, Abort is a component method, not Delphi Abort procedure. It
close
> > the connection.
>
> I'll look into it.
>
> > > - (known FPC bug) passing array of char or pchar to a method with
> > > ansistring as parameter doesn't work yet.
> >
> > Use StrPas.
>
> Could be a workaround, but ultimate goal is of course full source
compability
> for FPC.
>
> -----------------------
>
> (Message in the list)
>
> > > I don't exactly get what the message stuff does.  (I'm just starting
> > windows
> > > programming, I do *nix and Go32v2 usually)
> >
> > Windows has a message queue for each thread. The message queue is used
> > by the OS and applications to queue messages to signal events. Speaking
> > winsock, when data is available, winsock place a message in the
> > message queue for the thread owning the socket. Same with connect,
> > write and  other events. TWSocket process those messages and transform
> > most of them to events.
>
> So it is indeed windows that sends the messages. Hmm..  Have to discuss
> this with the other developpers, and some *nix folk. (if Linux can react
on
> socket availability, this could be reasonably native)
>
> > TWSocket also use messages to request for some operation to be done
> > after  the current event has been processed.
>
> > It is not easy to port a message based component to an environment
> > without  message processing. You cana chieve more or less the same
> > behaviour  using
> > threads (blocked waiting for something to happend such as
> > datavailable) and flags (to do some processing later). Probelm with
multithreading is to
> > find  a way to make a routine executable in one thread context when it
has
> > been triggered by a worker thread (a task similar to Delphi Synchronize
> > method  which is implemented using a message).
>
> More or less the same I thought. But (with the current sockets knowledge I
have
> it would only work for Select(), but I know nothing about async socks
under linux,
> except that they may exist :-)
>
>
>
> Marco van de Voort (MarcoV@Stack.nl or marco@freepascal.org)
>
>