I heard that tagging messages with references in Erlang as shown here (see part about references), will prevent the process to go through the all message queue when using "receive". Is that true?
Yes, see OTP-8623 in http://www.erlang.org/doc/apps/erts/notes.html#id65167
Related
We were recently reading the BEAM book as part of our reading group. In Chapter 7 there is an allusion to the ref trick/Synchronous Call Trick in Erlang.
Unfortunately, the book is incomplete and after discussion we were unable to figure out the ref trick was.
When performing a receive, the BEAM VM scans the mailbox in order to find the first suitable (matching) message, and blocks the process if it does not find any.
The 'trick' is that, since it's impossible for a new reference to be in the mailbox before it was created, there's no need to scan the whole mailbox when receive {Reference, Term}, only from the point where Reference was created.
That's the meaning of the following phrase:
The compiler recognizes code that uses a newly created reference (ref) in a receive (see [ref_trick_code]), and emits code to avoid the long inbox scan since the new ref can not already be in the inbox.
Suppose I have a single thread to keep writing logs using Log4j2 AsyncLogger, will the logs in the files follow the order of the calls? How many threads it uses to consume the log events?
The message order bug was fixed in version 2.10.0. So from this version the messages should be displayed in the order.
According to this answer there is only one thread that writes to file
I have configured Notifications as per blog in our S4Hana 1610(Embedded Architecture) Landscape.
But while checking bgRFC Monitor (Transaction sbgrfcmon), it is showing Data Not Available
Although I have
1.Created an RFC destination name IWNGW_BGRFC with transfer protocol Classic with bgRFC.
2.Created an RFC destination IWNGW_BEP_OUT_BGRFC for the background RFC queue with queue prefix set to Q.
3.Registered the IWNGW_BEP_OUT_BGRFC destination for background processing by creating a queue.
4.Supervisor destination BGRFC_SUPERVISOR already existed in the system.
Please guide.
Regards,
Rehan Sayed
Additional Attachments :
In transaction SM59 you can run a “Connection Test” on these RFC-destinations.
Is this working?
When you call transaction “sbgrfcmon”, which parameters do you provide at the selection screen?
Maybe a screenshot could help.
I think “sbgrfcmon” is a Monitor, where you will only see entries which are in error state or queued up, waiting for processing.
If you have no or only limited activity without any errors, you will be lucky, to see here any entries.
Please see also bgRFC Monitor
What happens if you produce some activity in the development system (maybe with errors) and keep refreshing “sbgrfcmon”?
The issue is resolved,since our system's SAP_BASIS component was on SP000 and it does not detect workflow maintained in SWF_PUSH_NOTIF1 transaction with Customizing set to 'X'.
Hence maintained workflow in SWF_PUSH_NOTIF1 transaction without Customizing and notification worked.
Regards,
Sayed
In my app, I plan to have many worker processes, that can potentially spend hours doing their work.
I want the user to be able to stop and delete the workers.
Is it acceptable to kill/2, exit the process?
Will it terminate the process even if it's in the middle of doing some work (i.e. downloading a file)?
Do supervisors offer a similar mechanism for stopping and removing children that are in the middle of doing some work?
Is it acceptable to kill, exit/2 the process? Will it terminate the
process even if it's in the middle of doing some work (i.e.
downloading a file)?
Yes. In order to terminate a process you may use exit/2 as you said. The termination procedure will be different if you set the Reason argument to be: noraml, OtherReason or kill.
It is explained very well in the Error Handling documentation, and also for more detailed explenation see this.
So you may choose whatever fits your application.
Do supervisors offer a similar mechanism for stopping and removing
children that are in the middle of doing some work?
Yes. As mentioned in the comment, there is a very good detailed documentation for it in Erlang's Supervisor documentation. I suggest you to carefully read all of it, but the main parts you're looking for are:
Defining the child_spec() when starting a child (mainly the shutdown and restart option).
terminate_child/2 for the actual termination of a child.
delete_child/2 for deleting a child after calling terminate_child/2.
You can read more about it here.
I really like the message passing primitives that D implements. I have only seen examples of message passing within a program though. Is there support for distributing the messages over e.g. a network?
The message passing functions are in std.concurrency, which only deals with threads. So, the type of message passing used to pass messages between threads is for threads only. There is no RMI or anything like that in Phobos. That's not to say that we'll never get something like that in Phobos (stuff is being added to Phobos all the time), but it doesn't exist right now.
There is, however, the std.socket module which deals with talking to sockets, which is obviously network-related. I haven't used it myself, but it looks like it sends and receives void[]. So, it's not as nice as sending immutable objects around like you do with std.concurrency, but it does allow you to do network communication via sockets and presumably in a much nicer manner than if you were using C calls directly.
Seems that this has been considered. From the Phobos documentation (found it through Jonathan M Davis answer)
This is a low-level messaging API upon
which more structured or restrictive
APIs may be built. The general idea is
that every messageable entity is
represented by a common handle type
(called a Cid in this implementation),
which allows messages to be sent to
in-process threads, on-host processes,
and foreign-host processes using the
same interface. This is an important
aspect of scalability because it
allows the components of a program to
be spread across available resources
with few to no changes to the actual
implementation.
Right now, only in-process threads are
supported and referenced by a more
specialized handle called a Tid. It is
effectively a subclass of Cid, with
additional features specific to
in-process messaging.