Commit Graph

364 Commits

Author SHA1 Message Date
Pierre Muller
930596bd85 Fix directories for some source files, based on suggestion by Alfred Glänzer in #40995 2024-11-19 22:12:31 +00:00
Nikolay Nikolov
2cefdd35b5 + WASI threads: define FPC_WASM_WORKER_THREADS_CAN_WAIT. It is actually true in
all known cases (command line WASI or browser).
2024-11-07 01:41:22 +02:00
Nikolay Nikolov
37b7835b12 + added unit unix98pty. Only enabled for linux, for now, but can be enabled in the future on other unix-likes. 2024-10-19 16:11:25 +03:00
Kirill Kranz
52651a7ede First compiler Build 2024-09-29 16:56:18 +03:00
Nikolay Nikolov
00e5289967 * WebAssembly threads: fix race condition, which causes sometimes an abandoned
basic event to be reported as signalled. This should fix the test tbrtlevt.pp
  sometimes failing.
2024-09-03 03:18:21 +03:00
Nikolay Nikolov
ccbc28dd85 * WebAssembly: fixed SysUtils.sleep() with large timeouts causing incorrect time
delay, due to arithmetic overflow
2024-09-03 02:30:14 +03:00
Nikolay Nikolov
0314ba9bfd * WebAssembly threads: in TThread.WaitFor, call CheckSynchronize in a loop,
while waiting on a thread that isn't finished, but the waiting happens on the
  main thread. This fixes the hang in test tb0636.pp
2024-09-03 01:19:51 +03:00
Nikolay Nikolov
919f8f383d * fixed compilation error, introduced in a0ac317aae 2024-08-23 13:33:25 +03:00
Nikolay Nikolov
a0ac317aae + WebAssembly threads: spinwait until ThreadHasFinished becomes true in
WasiWaitForThreadTerminate, before freeing the thread TLS and stack block, to
  avoid race condition with a thread that is finishing (i.e. the main threadproc
  is done), but still executing internal Pascal code inside
  FPCWasmThreadStartPascal.
2024-08-23 12:12:16 +03:00
Nikolay Nikolov
7fe6438d44 + WebAssembly threads: initialize TWasmThread.ThreadHasFinished to false in WasiBeginThread 2024-08-23 12:09:12 +03:00
Nikolay Nikolov
492e38069c + WebAssembly threads: introduced TWasmThread.ThreadHasFinished boolean 2024-08-23 12:07:21 +03:00
Nikolay Nikolov
6dfd2de188 + WebAssembly threads: call FreeStackAndTlsBlock in WasiWaitForThreadTerminate 2024-08-23 11:34:08 +03:00
Nikolay Nikolov
4abbd82135 * WebAssembly threads: made FreeStackAndTlsBlock set the StackBlock and
TlsPointers to nil
2024-08-23 11:32:15 +03:00
Nikolay Nikolov
c8b9eb3c5c * WebAssembly threads: moved the thread stack and TLS block free code to a new
procedure: FreeStackAndTlsBlock. No functional changes.
2024-08-23 11:24:02 +03:00
Nikolay Nikolov
df26a02d9d + WebAssembly threads: set FThreadReaped to true in TThread.WaitFor, to avoid
hang in TThread.SysDestroy after .WaitFor
2024-08-22 19:33:30 +03:00
Nikolay Nikolov
017b41de89 * WebAssembly threads: RTLEvents rewritten to implement an auto reset event.
Previous implementation did a manual reset event. However, at least on Windows
  and Linux, an auto reset event is used.
2024-08-21 18:10:44 +03:00
Nikolay Nikolov
db1d903a11 * WebAssembly threads: use high(uint32) as MaxThreadSignal 2024-08-21 13:56:04 +03:00
Nikolay Nikolov
edf7b26f52 + WebAssembly threads: implemented basic events (both manual and auto reset) 2024-08-19 12:31:19 +03:00
Nikolay Nikolov
200fbf64a1 + WebAssembly threads: set IsMultiThread to true in WasiBeginThread 2024-08-19 08:36:45 +03:00
Nikolay Nikolov
02867fe918 + WebAssembly threads: initialize the ThreadId threadvar for the main thread 2024-08-18 12:00:06 +03:00
Michaël Van Canneyt
37c32a9eb7 * Explicitly specify path to include files 2024-08-08 09:59:40 +02:00
Nikolay Nikolov
af5c2d66c2 * removed TODO comment from WasiThreadSwitch 2024-08-07 18:26:19 +03:00
Nikolay Nikolov
5d058258fc + added some more comments in wasi_thread_start 2024-08-07 18:19:35 +03:00
Nikolay Nikolov
a0e1dce1fd * WebAssembly threads: call fpc_wasm32_init_tls from inline asm code to avoid
race condition in branchful exceptions mode
2024-08-07 18:17:38 +03:00
Nikolay Nikolov
fcfce9f2d5 * WebAssembly threads: implement WasiEndThread using exceptions. There's no
other way to end a thread in WebAssembly, except by ending the thread
  procedure. Therefore, the only way to implement WasiEndThread is to have it
  raise an exception and handle it at the outermost level. This, of course,
  requires one of the WebAssembly exception modes to be turned on, in order for
  this to work.
2024-08-07 17:58:11 +03:00
Nikolay Nikolov
e03389c6a8 * WebAssembly threads: destroy the event and mutex in WasiBeginThread in case wasi_thread_spawn fails 2024-08-07 17:06:03 +03:00
Nikolay Nikolov
77d592221a * WebAssembly threads: use New and Dispose instead of GetMem/FreeMem for allocating/freeing TWasmThread 2024-08-07 16:46:13 +03:00
Nikolay Nikolov
f23cc9ec6d * WebAssembly threads: free the stack block and TLS block in case wasi_thread_spawn fails 2024-08-07 16:44:44 +03:00
Nikolay Nikolov
9e0b2869a3 * WebAssembly threads: disable stack checking for the FPCWasmThreadStartPascal procedure 2024-08-06 07:07:41 +03:00
Nikolay Nikolov
9d771396ff + WebAssembly threads: init StackBottom (used for stack checking) more precisely
when starting a new thread. Precision is not that important for the stack
  checking itself, because it uses a stack margin of 16kb, so the previous
  value, set by InitThread is good enough, however it's easy to do it precisely,
  since we allocate the stack and pass a pointer to it in TWasmThread, so why
  not?
2024-08-06 07:01:28 +03:00
Nikolay Nikolov
da59711442 * WebAssembly threads: pass the stack size to InitThread when starting a new thread 2024-08-06 06:40:33 +03:00
Nikolay Nikolov
68f4191119 + WASI: set StackBottom on startup 2024-08-06 04:02:15 +03:00
Nikolay Nikolov
60bb6c19d9 + WASI: set StackLength on startup 2024-08-06 03:55:52 +03:00
Nikolay Nikolov
3c027b0ba0 * WebAssembly threads: use the stack size, specified for the main thread (via
the $M directive, or the '-Cs' compiler option) as the default stack size for
  other spawned threads
2024-08-05 01:59:13 +03:00
Nikolay Nikolov
a417b0db9b * WebAssembly threads: simplified (optimized) the implementation of
TWasmRTLEvent, so it doesn't use a Mutex. Use atomic operations instead.
2024-08-05 00:31:27 +03:00
Nikolay Nikolov
74a4550ff0 * WebAssembly threads: fix TThread.WaitFor (use -1 instead of 0 to signal infinite timeout) 2024-08-04 21:09:18 +03:00
Nikolay Nikolov
6be3a42a2f * WebAssembly: optimized SysOSAlloc to use memory area left at the end of the
page (64kb). This reduces memory use, when SysOSAlloc is called with sizes,
  smaller than 64kb.
2024-08-04 18:04:10 +03:00
Nikolay Nikolov
801f902efe * WebAssembly threads: fix threadvars with the new WASI-threads implementation 2024-08-04 05:50:06 +03:00
Nikolay Nikolov
7681c192db * WebAssembly threads: protect SysOSAlloc against race conditions via a critical section 2024-08-04 03:15:31 +03:00
Nikolay Nikolov
31bb06ac87 + WebAssembly threads: initial implementation of the WASI threads proposal:
https://github.com/WebAssembly/wasi-threads

  Note that the WASI folk have already declared this proposal 'obsolete' and
  only intended to be used for engines that support WASI v0.1. On the other
  hand, the WASI v0.2 threads proposal is an early draft and not implemented
  anywhere, so we have no choice, but to stay with v0.1 at this time, or give up
  on multithreading for who knows how long it would take for the v0.2 spec to be
  completed.

  Regarding the WASI v0.1 engines that implement WASI threads correctly and can
  be used with Free Pascal, I've discovered only one that works:

    https://github.com/bytecodealliance/wasm-micro-runtime/tree/main

  Wasmtime claims to support multithreading since version 15, however it doesn't
  seem to work. I tested all versions until the 23.0.1, and none of them works.

  Caveat: using the internal linker is not yet supported with WebAssembly and
  multithreading. Please use the external linker (the -Xe option), if you want
  to give this new feature a try.
2024-08-04 02:24:20 +03:00
Nikolay Nikolov
bb93b918a5 * WebAssembly threads: don't check for GetThreadState(MyThread)<>tsRunning in
LockMutexTimeoutWait and LockMutexTimeoutNoWait
2024-08-04 01:56:25 +03:00
Nikolay Nikolov
694341aa78 * WebAssembly threads: fixed bug in LockMutexTimeoutNoWait, caused by the use of
Result instead of Res. This stupid bug broke WebAssembly critical sections,
  causing random spurious hangs and it took me quite a lot of time to find it!
2024-08-04 00:37:16 +03:00
Nikolay Nikolov
c2fcb1a833 * WebAssembly threads: reformat code in LockMutexTimeoutNoWait for better
readability by removing begin..end blocks and replacing it with an 'else if'
  chain. No functional changes.
2024-08-04 00:33:44 +03:00
Nikolay Nikolov
e612401562 * WebAssembly threads: also access TRTLCriticalSection.Owner using atomic loads and stores 2024-08-03 02:58:32 +03:00
Nikolay Nikolov
6a1eb520e9 * WebAssembly threads: use atomic loads and stores for accessing TRTLCriticalSection.Locked 2024-08-03 02:51:27 +03:00
Nikolay Nikolov
41ead20bfb * WebAssembly threads: fixed race condition LockMutex in the check where Locked
is 1, but Owner still holds the current thread id, even though another thread
  has just acquired a lock, but still haven't updated the owner thread ID. We
  avoid this problem by setting Owner to nil before unlocking the mutex. And in
  InitMutex/DoneMutex, we store the creator thread ID in a different field -
  Creator, instead of Owner.
2024-08-03 02:34:05 +03:00
Nikolay Nikolov
692bd62359 * WebAssembly threads: bug fixes in LockMutexTimeoutWait 2024-08-03 01:29:04 +03:00
Nikolay Nikolov
a179ca8cf8 * WebAssembly mutex: changed the timeout parameter to be in nanoseconds (these
functions are only used internally, so this doesn't break compatibility)
2024-08-02 23:10:06 +03:00
Nikolay Nikolov
a21dfc0245 * WebAssembly mutex: changed the aTimeoutMS parameters of LockMutexTimeoutNoWait
and LockMutexTimeoutWait to int64, instead of longint, since they're called
  from LockMutexTimeout, which takes an int64 parameter
2024-08-02 23:02:33 +03:00
Nikolay Nikolov
6d45fd09a2 * WebAssembly mutex: treat all negative values of aTimeoutMS as infinite, instead of just -1 2024-08-02 22:59:31 +03:00