• Places
    • Home
    • Graphs
    • Prefixes
  • Admin
    • Users
    • Settings
    • Plugins
    • Statistics
  • Repository
    • Load local file
    • Load from HTTP
    • Load from library
    • Remove triples
    • Clear repository
    • RDF quality heuristics
  • Query
    • YASGUI SPARQL Editor
    • Simple Form
    • SWISH Prolog shell
  • Help
    • Documentation
    • Tutorial
    • Roadmap
    • HTTP Services
  • Login

10.3.3 Signalling threads
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
      • Multithreaded applications
        • Thread communication
          • Signalling threads
            • thread_signal/2
    • Packages
Availability:built-in
thread_signal(+ThreadId, :Goal)
Make thread ThreadId execute Goal at the first opportunity. In the current implementation, this implies at the first pass through the Call port. The predicate thread_signal/2 itself places Goal into the signalled thread's signal queue and returns immediately.

Signals (interrupts) do not cooperate well with the world of multithreading, mainly because the status of mutexes cannot be guaranteed easily. At the call port, the Prolog virtual machine holds no locks and therefore the asynchronous execution is safe.

Goal can be any valid Prolog goal, including throw/1 to make the receiving thread generate an exception, and trace/0 to start tracing the receiving thread.

In the Windows version, the receiving thread immediately executes the signal if it reaches a Windows GetMessage() call, which generally happens if the thread is waiting for (user) input.

ClioPatria (version V3.1.1-40-g9d9e003)