WEBVTT 00:05.180 --> 00:12.530 Now, the third API that we will going to discuss is is the API using which a process can actually enqueue 00:12.560 --> 00:14.360 a message in the message queue. 00:14.390 --> 00:20.900 So ascending process can place a message in the message queue using the API, mq underscore send. 00:21.020 --> 00:22.820 So this is the API. 00:22.850 --> 00:27.710 The first argument to this API is a file descriptor to the message queue. 00:28.010 --> 00:32.420 The second argument is the pointer to the message which you want to send. 00:32.570 --> 00:36.790 And the third argument is actually the length of the message in bytes. 00:36.800 --> 00:42.860 And the fourth argument is actually a certain priority, which you can always attach to the message 00:42.860 --> 00:44.240 that you are trying to send. 00:44.660 --> 00:48.770 The return value of this API is actually zero on success. 00:48.770 --> 00:54.860 That is, if the message queue send API is successfully able to send a message to the receiving process, 00:54.860 --> 00:57.470 then this API returns zero on success. 00:57.470 --> 01:01.670 And if for some reason this API fails, then it returns failure. 01:03.890 --> 01:10.830 All right, so message you send is an API used for sending a message to the queue referred to by the 01:10.830 --> 01:12.450 file descriptor message queue. 01:12.450 --> 01:18.660 So this is the message queue file descriptor and of course the message pointer is a pointer to the message 01:18.660 --> 01:20.160 buffer which you want to send. 01:20.280 --> 01:27.090 And message length is the size of the message which you are trying to send and of course the size of 01:27.090 --> 01:32.910 this message which you are trying to send should be less than or equal to the size of the message which 01:32.910 --> 01:35.490 you set in the attributes of this message queue. 01:35.970 --> 01:38.850 Now the third argument that is message priority. 01:38.880 --> 01:44.640 You can always attach some non-negative priority to the message that you are trying to send using message 01:44.640 --> 01:45.180 queue. 01:45.180 --> 01:51.270 So message priority is actually a non-negative number specifying the priority of the message. 01:51.510 --> 01:59.250 Messages are placed in the queue in the decreasing order of message priority and with the older messages 01:59.250 --> 02:02.250 for a priority coming before the newer messages. 02:02.640 --> 02:09.940 So suppose you have a message queue and at any point of time suppose you have a message M1, M2, M3 02:09.940 --> 02:13.480 And let us say the priority of this message is 211. 02:13.480 --> 02:18.610 And now suppose the sending process enqueue the message in the message queue with the priority say four. 02:18.880 --> 02:26.110 So this message will be added to the message queue right in the front because it has the priority four. 02:26.110 --> 02:32.350 So it is this message that will be delivered to the receiving process before the older messages which 02:32.350 --> 02:34.210 were already there in the message queue. 02:34.300 --> 02:39.730 Because the priority of the message that is placed in the message queue takes a precedence. 02:40.300 --> 02:42.700 But anyways, it is some advanced feature. 02:42.700 --> 02:47.950 Probably we will not be going to use the priority of the message queue in our assignments. 02:50.150 --> 02:58.070 Now, the next point is that if the message queue is full and if the process is trying to place an additional 02:58.070 --> 03:05.090 message to the message queue using message queue, send API, then by default this API will get blocked 03:05.120 --> 03:09.110 because there is no room for an additional message to the message queue. 03:09.320 --> 03:10.070 Right. 03:10.070 --> 03:13.910 And it will stay blocked till there is a space on the message queue. 03:14.640 --> 03:15.030 Right. 03:15.030 --> 03:18.000 So this is the default behavior of the message queue. 03:18.030 --> 03:26.340 However, during the creation of a message queue, if the flag specified is non-block flag, that is, 03:26.340 --> 03:32.070 if this flag was specified in the message queue open system call. 03:32.220 --> 03:39.870 It would mean that in the scenario when the message queue was full and message queue send API was invoked 03:39.870 --> 03:46.470 on the message queue to place an additional message in the message queue, then this function call will 03:46.470 --> 03:47.700 immediately return. 03:47.700 --> 03:50.250 It will not block right. 03:50.250 --> 03:56.910 So message queue send function will return immediately if the message queue is full and the global variable 03:56.910 --> 04:00.060 that is error number will be set to E again. 04:00.900 --> 04:03.330 So this is the purpose of this flag. 04:03.330 --> 04:11.280 That is whether you want the message queue send function to get block or not in a scenario when the 04:11.280 --> 04:12.990 message queue was full. 04:13.740 --> 04:20.680 So this API that is message queue send is simply is very simple and straightforward API. 04:20.710 --> 04:26.560 So the next we will going to discuss the API to a message from a message queue.