I'm developing a cross platform social computing platform that implements HTTP, XMPP, WebSockets (and more) part of the core principals is to offer scalability across transports. When I started this project, about 4 years ago, it was under Delphi and Win64; and I left Delphi to offer this product on MAC and *nix platforms. Well, I'm nearly ready to release but had to address a few issues first.

I have committed to deprecating polling in place of signaling and presently have no way of knowing when data has arrived or a socket has been closed under every other OS other than Windows. :-)

One of the biggest current issues is with abnormal latencies with regard to my cross platform implementation of sockets using a application level polling mechanism. Having tested server implements across various transports - I determined it was worth the effort to re-introduce event driven signaling and deprecate polling. I need to access kernel level code but have just starting reading about caveats on *nixes.

http://wiki.lazarus.freepascal.org/Main_Loop_Hooks

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2003-10/0168.html

Presently, I have a cross platform mechanism for socket signals and "integrated" my windows code for Windows 32/64 builds. Not much testing was needed as I just borrowed code and ifdef Windows and included windows sockets which comes with signaling capabilities.

I want to tie into some sort of system under Lazarus or FPC libraries that offer (high scale) cross platform support using signaling. I found "Main Loop Hooks" for Lazarus but wanted to know if it can be used for sockets and how scalable is it. Anyone have any comments or thoughts regarding this?

Anyone want to respond with some basic semantics regarding signals and socket handles under Linux/Unix?

I noticed some POSIX code being added to FPC. Does anyone want to comment on the use of POSIX libraries to implement asynchronous signaled sockets?

I do want to say that it would be important to me not to have to call too many methods along the way as it would add inefficiencies and reduce performance as any callback or handler would be called tens of thousands of times per minute and is what signals my engine across many different server implements under the SAME process. Meaning I want then socket identifier in the callback function - I don't want to make an additional call to get the id of the socket.

Any help would be greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101230/6fcd015d/attachment.html>

It can be used with handles.

Anyone want to respond with some basic semantics regarding signals and socket handles under Linux/Unix? ?

In short: on unix, you're better off with select() and friends. (which is basically what the main loop hooks in lazarus do)

I have no knowledge of an actual signaling mechanism for data. epoll, select, poll all use a wait loop.

Michael.

aio_read ?

This is not a signalling mechanism in the sense that you get a message if data is available for reading. It's an asynchronous read. You must call aoi_error() at intervals to see if the data has been read.

Michael.

Do you want to handle the socket in a thread and schedule an event in the main thread to make it react on the received data ?

If so, "SendMessage()" -> "procedure... message"; used to work perfectly for all OSes in the released version of Lazarus, but seems to be broken in the current Linux svn version.

Of course this is kind of "Windowish", but Lazarus used to have a cross platform implementation.

-Michael

P.S.:

Delphi has TThread.Queue for this, Which does not seem to be implemented in FPC (see Bug Tracker ID 0017297 by Marco)

-Michael

I'm already knee deep into a solution for Linux and my Windows implement was already tested before I started (I had the code from Delphi). I just had to create framework for methods that fit for all OSes. So in this regard the semantics of my app are already fleshed out.

But APC QUEUE method was unique to windows. It is called via the thread after it cycles and awakes during execute. I found that very useful for protecting memory access from other threads.

The trick would be to find the equivalent under Linux.