mdbergmann / cl-gserver Goto Github PK

There should be a configuration file, based on lisp, that is read when starting an actor system.
But there should also be a fallback internal representation of this config in case when the user just wants defaults.

Hi,
if I run this on my emacs-slime repl:

(future:on-completed (act:ask *answerer* "Buzz") (lambda (result) (format t "Received result: ~a~%" result)))

I get something like this:
#<BLACKBIRD-BASE:PROMISE name: "attach: PROMISE" finished: NIL errored: NIL forward: NIL {10025761C3}>

(if I hit enter again I get ;no value)

And if I run something like this:
(act:tell *answerer* "hello")
I get :STOPPED as result.

Is there a problem or should I use another method to capture the result?
Thanks!

In order to avoid handlers changing the state of a GServer as a side-effect, only a copy of the state object should be passed in to the message handlers (handle-cast, handle-call, receive).

https://github.com/melisgl/mgl-pax

And create a factory function to create new 'message-boxes'.

Don't lock the user in to log4cl. Let the user chose the logging library.

Hello,
nice project!
I couldn't use (child) actors as the context to ac:find-actors and ac:all-actors.
Is that functionality provided?
Thanks.

This will be more performant for lookups on actor name (and later path)

ABCL currently is broken as it still implements the old interface.

added also some images

In a heavy multi-threaded environment, as in the mp-test, the index variable and the update of it is not atomic enough.
Looking for a better way. stmx or atomics (cas) maybe, but that'd pull another dependency.

Returning a cons can be a bit of a pain when nothing is to be returned to the caller.

So it should be possible to not return a cons.
The state can be modified by other means, i.e. accessing act-cell:state directly, or by a convenience accessor.
While doing that within the receive function it's still thread-safe.
Sending a response to a caller must be done manually in that case but the sender has to be exposed then to the receive function context.

We can still define a max queue size and enforce it with back-pressuring.

Hi,

As I checked some codes of cl-gserver, there're several files use atomic operation.

1. atomic.lisp, which defines atomic-cas, in this method definition, (when cas-result (setf ....) is really redundant, cas can make sure it's been set if cas succeeds. Furthermore, the setf after cas may be dangerous, this is usually a trap and is hard to debug.
2. router.lisp, which defines make-round-robin-strategy, this function returns a lambda which always returns the new value, however, the cas operation may fail and leave the atomic-integer not changed, this might make the returned value not what you want.
3. actor-context.lisp, in the definition of %add-actor, cas can make sure that a new actor will be successfully added in a loop. And finally, in the definition of %remove-actor, a single cas can not make sure it's removed successfully without a loop.

Since I just grepped the lisp file with atomic, and you may have some codes in other files which make sure all these are OK. But if you can confirm that these functions should get enhancement, I'm glad to make a patch.

I am most probably abusing cl-gserver here but I was trying to test breaking up a long running task into many actors but all the sub actors dont complete their futures. Is it a bug or am I really messing up. (Just as a note I tried to create the sub actors as actors of the system or as actors of the main actor and the result is the same.)

There is a break in the code to show where things get stuck.

(defparameter *system* (asys:make-actor-system))

(defun blocking-task-spread-work ()
  ;;Message processing is blocked untill the main task is returned, 
  ;;The actual work is split between many actors and we wait for all of them
  ;;to finish
  
  (let ((blocking-actor
	  (ac:actor-of
	   *system*
	   (lambda ()
	     (act:make-actor 
	      (lambda (self msg state)
                                     
		(let ((output (get-universal-time)))
				       
		  (format t "~a : ~a : ~a~%" (act-cell:name self) msg output)
		  (if state
		      (cons output state)
		      (progn
		
			(let ((futures))
			  
			  (dotimes (i 5)
			    (push 
			     (act:ask
			      (ac:actor-of (act:context self) 
					   (lambda ()
					     (act:make-actor
					      (lambda (child-self msg state)
						(declare (ignore child-self))
						(let ((output msg))
						  (format t "~a : ~a~%" (act-cell:name self) output)
						  (sleep 1)
						  (cons output state)))
					      :name (format nil "child-~A" i))))
				      "Load Shard")
			     futures))

			  (loop do (break "~A" futures)
				until (every #'future:complete-p futures)))
			
			(cons output t)))))
	      :name "long-task")))))

    (future:on-completed
     (act:ask blocking-actor "Load shards" )
     (lambda (result)
	 (format t "Received final result: ~a~%" result)))
    
    (ac:stop *system* blocking-actor)))

(blocking-task-spread-work)

..to allow computing a result using a thread pool, to not block the message queue handling.
In this case though a sender must be available in case a response is expected.
So this will only work for tell and async-ask.

Remoting in the sense of having actor systems on different hosts where sending messages is location transparent.
Meaning actor A in system A can send and receive message to/from actor B in system B.

The path of the actor thus has to be extended to specify an URI, like: clg://<host>/<actor-system-name>/<actor-path>

Hi, this issue may relate to bordeaux-threads' issue 29, where you left an discussion and you said APIv2 worked.

In cl-gserver, bt:condition-wait was used directly (src/queue/queue.lisp), however, according to my tests, spurious wakeups may occur even with APIv2. I raised an issue for bordeaux-threads with my test code, and the author confirmed that it's right to use condition-wait in a loop.

I don't know why the same test code failed in my laptop and why it passed in the author's laptop, however, I think it's better to wrap condition-wait within a loop. The missed signals and spurious wakeups of condition variable wasted me a lot of time when I used it in a thread pool as they occured very very rarely.

Right now lparallel is used directly in the GServer to handle the incoming messages and such.
This should be abstracted behind an interface.
This interface may have different implementations: lparallel, BT, green-threads.

Current limitation are the atomics which have no support for CLisp.
But there may be a specialized implementations based on locks instead.

Can't be compiled on Clasp 1.0

send back error condition when timeout elapses.

An event stream can be used for event based notifications within the actor system.

Actor can subscribe to events, which are completely defineable by users and may just be atoms.
When an actor did subscribe to an event and the event is raised, then in order to receive the notification the actor has to listen to it in the receive/behavior function.

As for #34, it would make sense to unify the 2 data structure agents considering how similar they are.

But the CL standard uses different APIs for the two: assoc for alists and getf for plists.

If we are going to follow CL, then we can make serarate agents.
If not, we can unify the interfaces. But then, why not unify the plist/alist interface with that of hash-tables?

Since they are index-based, it makes sense to have a common interface for them. But CL uses nth for lists and elt for vectors, so it would not follow the standard here (which is my opinion not very convenient).

Otherwise they can be separate interfaces.

Well, it is kind of thread-safe via modifying and swapping the list instance.
But actor instances could get lost when actors are added/removed from multiple-threads.

This should be supported by some CAS mechanism.

When I try to build the latest cl-gserver, i get this during build:

<WARN> [10:54:29] cl-gserver gserver.lisp (handle-message fun5) - Error condition was raised on message processing: CL-GSERVER::C: #<UNDEFINED-FUNCTION NIL {100D520B13}>

It stalls from there and does not time out or proceed.

ASK-S--SHARED--TIMEOUT in ACTOR-TESTS [Tests for ask-s timeout.]:
Unexpected Error: #<SIMPLE-ERROR {63800EA7}>
Attempt to release lock not held by calling thread..

'async-ask' should be 'ask'.
and 'ask' should be 'ask-s' for 'synchronous'.

Since the old 'async-ask' is implemented using 'tell' both 'tell' and 'async-ask' do support the 'sender'.

Agents and facades are a great abstraction for concurrent access to any kind of data.
It'd be great to provide an abstraction to commonly used data, such as hash tables and maybe lists, plists, vectors, etc.

Example:

(setf *facade* (make-facade-hash-table))
  
; then

(facade-get *facade* INDEX)
(facade-set *facade* INDEX VALUE)

This could be done pretty cleanly and safely by declaring the facades in separate packages.

Thoughts?

Already implemented as of version 1.7.0.
See documentation.

As part of this, rename the constructor parameter 'behavior' back to 'receive-fun'.
Switching behavior via 'become' and the default 'receive' are two different things.

cl-gserver currently only sets (setf) the value of state in (cons back-msg state) to the actor state. It does not make a deep copy to maintain immutable environments. This is up to the user.
However, it could provide at least a model mix-in that defines a generic function make-copy which implementer scan implement to make a deep copy of a component that cl-gserver could automatically use when setfing the state.

Issues #34 and #35 raise the question of genericity for container-wrapping agents.

What if we provided CL-abiding agents for lists, plists, etc. and then another agent that would wrap https://alex-gutev.github.io/generic-cl/ containers? This way the user would have the choice between the standard CL API, or a common (and extensible) API for all kinds of data structures.

Loads of error like these:

While computing the class precedence list of the class named CL-GSERVER.ACTOR:ACTOR.
The class named #:ACTOR-CELL is a forward referenced class.
The class named #:ACTOR-CELL is a direct superclass of the class named CL-GSERVER.ACTOR:ACTOR..

cl-gserver can't be deployed on ABCL.

System info:
Macbook pro 2019, core i7, 16GB ram, big sur 11.3.1
ABCL 1.8.0

It seems that "cl-murmurhash" has a problem.

`[package cl-murmurhash]
; in (DEFMACRO ~> ...)

; Caught STYLE-WARNING:
; ; Note: deleting unused local function FLET ENLIST

...........................
...........
#<THREAD "interpreter" {4EFAFE9}>: Debugger invoked on condition of type STORAGE-CONDITION
Stack overflow.
Restarts:
0: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-murmurhash" "cl-murmurhash">.
`

Timeout is currently very expensive as a thread is spawned with a sleep.
For sure there is a better approach than wasting a full thread.

... and that automatically uses a thread pool of workers that can do the heavy lifting work of Actors.

1.7.3 and 1.7.4 are not on the public repo if I'm not mistaken.

Could you push them? It makes it easier for packagers to package the right version (e.g. in Nix and Guix).

Suppose there are A1, A2, ..., A10, 10 actors, they ask-s B1, B2, ..., B10 with "time-out" in the same time.
And B1, B2, B10 are all time-out, and they throw 10 handler-error in the same time. How does the handler deal with this situation? Or ask-s should not throw exception, and just return a "fail" value?