Fiber Library

[Fiji]

I am trying to port this Delphi library to FPC however the problem is assembler. If ported it could run on linux, android etc.

I thought it can be ported to 64 bit just by changing EAX->RAX but I was wrong...

[Laksen]

That's some very Windows 32-bit specific code. There won't be an easy way to get that running on Linux or any other processor type

[Fiji]

Well it doesn't use any WINAPI code. Only stack swapping and exception handling.

[ttomas]

This is good starting point for porting to FPC and be cross platform.
Raudus have similar functionality and I think is cross platform (free but not open source)
http://raudus.wikispaces.com/Internals+-+Multithreading
This will be ideal for async TCP/HTTP servers. In OnReceive event you can write something like this:

Code: [Select]

  // Prepare DB Requests
  RaApplication.Application.EnterMultithreadSection;
  try
    // this code will work in working thread and don't block event loop
    ...
    // DB Access and long time processing
  finally
    RaApplication.Application.LeaveMultithreadSection;
  end;
  // Return to main thread (event loop thread)
  // Process Response
or in Fiber DemoForm.pas

Code: [Select]

        try
          // Switch to worker thread

          TFiber.Current.SwitchToWorkerThread;
          Http := TIdHttp.Create(nil);
          Http.AllowCookies := True;
          Http.HandleRedirects := True;
          Http.Get('http://www.cnn.com');
          Http.Free;

        finally
          // Switch back to main thread
          TFiber.Current.SwitchToMainThread;
        end;


[Fiji]

At this point its only a dream unless some ASM expert steps up.

[Leledumbo]

Well it doesn't use any WINAPI code. Only stack swapping and exception handling.

ActiveX? Sure it doesn't use any Windows-ism? It does use WinAPI's threading solution. And x86-ism as well.

[Fiji]

Well no it does not use any ActiveX it seems you haven't even looked at it.
Besides TThread is available on FPC aswell. Only ASM code is the problem.

Code: [Select]

unit DphThreadPool;

interface

uses Windows, SysUtils, Classes, SyncObjs;

unit DphFibers;

interface

uses Windows, Classes, SysUtils{$ifdef threading}, DphThreadPool{$endif};

[Leledumbo]

Well no it does not use any ActiveX it seems you haven't even looked at it.
Besides TThread is available on FPC aswell. Only ASM code is the problem.

Code: [Select]

unit DphThreadPool;

interface

uses Windows, SysUtils, Classes, SyncObjs;

unit DphFibers;

interface

uses Windows, Classes, SysUtils{$ifdef threading}, DphThreadPool{$endif};

Look at the implementation's uses clause. Even if you commented it out, look at those CoInitializeEx, CoUninitialize, CreateSemaphore, CreateEvent and their friends. Haven't looked at it? Perhaps you should dig it deeper first. Try compiling on non-Windows platform, you'll see it immediately.

[Fiji]

CoInitializeEx, CoUninitialize can be removed. The rest are standard sync objects.

[Leledumbo]

CoInitializeEx, CoUninitialize can be removed. The rest are standard sync objects.

Certainly no, they don't exist in my Linux. I (and Laksen) told you it's Windows specific, still don't believe? I said try it on a non-Windows OS. You can't see what we, non-Windows users see, if you still develop on Windows box. Cross platform development requires respective target environment to test, either directly or emulated.

[marcov]

Note that the pascal code also contains 64-bit unclean code, which needs fixes, also for Delphi 64-bit.

Code: [Select]

  FFiberContext.CESP := Pointer(Cardinal(Stack) + StackSize);
This typecasts a 64-bit type (stack) to a 32-bit type (cardinal).

Some other things:
    1. Also it might be possible to replace the "event" stuff with TEvent, (depending of the set of parameters to createvent is supported by TEvent in some way).
    2. If that doesn't work, there is basic semaphore and event stuff in the FPC threadmanager (the platform dependent part that the OS independent part interfaces to).
    3. The WaitForMultipleObjects is going to be difficult. Classically, Linux doesn't have this kind of primitive for semaphores. (only for fileselectors with Select())
    4. The code uses TThread.Queue() a lot which is only available in trunk versions of FPC.

Note that before porting it to Linux I would first time the linux thread implementation, and see if you can reduce the stack size with other means to reach high thread counts. The dynamics of all thread libraries are different.

[Fiji]

So it can be ported? Without the activex stuff?

[marcov]

So it can be ported? Without the activex stuff?

To win64: maybe. Still would require some knowledge.

Not without fully understanding both the current windows implementation and everything related on Linux.

 "Fibers" as a concept is already Windows centric.

P.s. updated the above answer some more after a second look.

[Fiji]

Here is a cross platform solution in C++

https://github.com/mozy/mordor

[marcov]

Here is a cross platform solution in C++

https://github.com/mozy/mordor

Good luck porting that (AND Boost)