This file is indexed.

/usr/include/simgrid/s4u/Mailbox.hpp is in libsimgrid-dev 3.14.159-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
/* Copyright (c) 2006-2015. The SimGrid Team. All rights reserved.          */

/* This program is free software; you can redistribute it and/or modify it
 * under the terms of the license (GNU LGPL) which comes with this package. */

#ifndef SIMGRID_S4U_MAILBOX_HPP
#define SIMGRID_S4U_MAILBOX_HPP

#include <string>

#include <xbt/base.h>

#include <simgrid/s4u/forward.hpp>
#include <simgrid/s4u/Actor.hpp>

namespace simgrid {
namespace s4u {

/** @brief Mailboxes: Network rendez-vous points.
 *  @ingroup s4u_api
 *
 * @tableofcontents
 *
 * @section s4u_mb_what What are mailboxes
 *
 * Rendez-vous point for network communications, similar to URLs on
 * which you could post and retrieve data. Actually, the mailboxes are
 * not involved in the communication once it starts, but only to find
 * the contact with which you want to communicate. 

 * Here are some mechanisms similar to the mailbox in other
 * communication systems: The phone number, which allows the caller to
 * find the receiver. The twitter hashtag, which help senders and
 * receivers to find each others. In TCP, the pair {host name, host
 * port} to which you can connect to find your interlocutor. In HTTP,
 * URLs through which the clients can connect to the servers.
 *
 * One big difference with most of these systems is that usually, no
 * actor is the exclusive owner of a mailbox, neither in sending nor
 * in receiving. Many actors can send into and/or receive from the
 * same mailbox.  This is a big difference to the socket ports for
 * example, that are definitely exclusive in receiving.
 *
 * A big difference with twitter hashtags is that SimGrid does not
 * offer easy support to broadcast a given message to many
 * receivers. So that would be like a twitter tag where each message
 * is consumed by the first coming receiver.
 *
 * The mailboxes are not located on the network, and you can access
 * them without any latency. The network delay are only related to the
 * location of the sender and receiver once the match between them is
 * done on the mailbox. This is just like the phone number that you
 * can use locally, and the geographical distance only comes into play
 * once you start the communication by dialling this number.
 *
 * @section s4u_mb_howto How to use mailboxes?
 *
 * Any existing mailbox can be retrieve from its name (which are
 * unique strings, just like with twitter tags). This results in a
 * versatile mechanism that can be used to build many different
 * situations.
 *
 * For something close to classical socket communications, use
 * "hostname:port" as mailbox names, and make sure that only one actor
 * reads into that mailbox. It's hard to build a prefectly realistic
 * model of the TCP sockets, but most of the time, this system is too
 * cumbersome for your simulations anyway. You probably want something
 * simpler, that turns our to be easy to build with the mailboxes.
 *
 * Many SimGrid examples use a sort of yellow page system where the
 * mailbox names are the name of the service (such as "worker",
 * "master" or "reducer"). That way, you don't have to know where your
 * peer is located to contact it. You don't even need its name. Its
 * function is enough for that. This also gives you some sort of load
 * balancing for free if more than one actor pulls from the mailbox:
 * the first relevant actor that can deal with the request will handle
 * it.
 *
 * @section s4u_mb_matching How are sends and receives matched?
 *
 * The matching algorithm is as simple as a first come, first
 * serve. When a new send arrives, it matches the oldest enqueued
 * receive. If no receive is currently enqueued, then the incomming
 * send is enqueued. As you can see, the mailbox cannot contain both
 * send and receive requests: all enqueued requests must be of the
 * same sort.
 *
 * @section s4u_mb_receiver Declaring a receiving actor
 *
 * The last twist is that by default in the simulator, the data starts
 * to be exchanged only when both the sender and the receiver are
 * declared while in real systems (such as TCP or MPI), the data
 * starts to flow as soon as the sender posts it, even if the receiver
 * did not post its recv() yet. This can obviously lead to bad
 * simulation timings, as the simulated communications do not start at
 * the exact same time than the real ones. 
 * 
 * If the simulation timings are very important to you, you can
 * declare a specific receiver to a given mailbox (with the function
 * setReceiver()). That way, any send() posted to that mailbox will
 * start as soon as possible, and the data will already be there on
 * the receiver host when the receiver actor posts its receive().
 *
 * @section s4u_mb_api The API
 */
XBT_PUBLIC_CLASS Mailbox {
  friend Comm;
  friend simgrid::s4u::Engine;
  friend simgrid::simix::Mailbox;

  simgrid::simix::Mailbox *pimpl_;

  explicit Mailbox(smx_mailbox_t mbox): pimpl_(mbox) {}

  /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */
  friend void intrusive_ptr_add_ref(Mailbox*) {}
  /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */
  friend void intrusive_ptr_release(Mailbox*) {}
public:
  /** private function, do not use. FIXME: make me protected */
  smx_mailbox_t getImpl() { return pimpl_; }

  /** Gets the name of that mailbox */
  const char *name();

  /** Retrieve the mailbox associated to the given C string */
  static MailboxPtr byName(const char *name);

  /** Retrieve the mailbox associated to the given C++ string */
  static MailboxPtr byName(std::string name);

  /** Returns whether the mailbox contains queued communications */
  bool empty();

  /** Gets the first element in the queue (without dequeuing it), or nullptr if none is there */
  smx_activity_t front();

  /** Declare that the specified actor is a permanent receiver on that mailbox
   *
   * It means that the communications sent to this mailbox will start flowing to
   * its host even before he does a recv(). This models the real behavior of TCP
   * and MPI communications, amongst other.
   */
  void setReceiver(ActorPtr actor);

  /** Return the actor declared as permanent receiver, or nullptr if none **/
  ActorPtr receiver();
};

}} // namespace simgrid::s4u

#endif /* SIMGRID_S4U_MAILBOX_HPP */