This is WAI isn't it? I don't know of any Chrome OS devices that are able to advertise and hold a gatt connection at the same time. If I remember correctly only devices with BT 4.2 are able to do this.

I believe Luis is saying that advertising from the local machine stops if another device connects to the GATT server running on the local machine. That shouldn't require 4.2?

I could be completely wrong, but my understanding was that you cannot advertise and make "outgoing" GATT connections.

Yup, that's what I meant. I was under the impression that you needed support for multiple advertisements for that which was only added in 4.2. I actually never read the spec regarding this but that was my understanding based on the Android APIs, so I could be completely wrong.

Ah. I'll look in the 4.0 spec again and mark the bug accordingly.

We talked about this once, the restrictions are written in [Vol.6 Part B. 1.1] of spec 4.0 and spec 4.2.

In 4.0, these two restrictions explain why the advertising stops when the device is connected as a slave role.
This combination is also marked as prohibited in Table 1.1.
 (1) When entered from the Advertising State, the Connection State
shall be in the Slave Role.
 (2) If the Link Layer is already operating in the Connection State or Initiating
State, the Link Layer shall not operate in the Advertising State with a type of
advertising that could result in the Link Layer entering the Connection State
in the Slave Role.

Although in 4.2, (1) still applies, it has different rules on roles and the allowed number of state machine
This combination can be found in Table 1.1 Combination A at row 3(if starting from 0).
The Link Layer may have multiple instances of the Link Layer state machine, and multiple state machines can be active at a time, so one state machine can be in connection (Slave role) while there is another state machine does the advertising.

Maintaining a connection and a advertising in parallel may not be possible even if the controller can do it, depending on the parameters used it wouldn't be possible for the scheduler to attend both modes. Also it is very weird to continue, at least it should advertise as connectable again.

Btw, the multiple advertisement support doesn't seems to be an adopted Bluetooth concept, there doesn't exist any HCI command for it, so it is probably only available as a vendor command to Android, etc, which is why is so complicated to treat it as there is no document explaining what should be the expected behavior. In fact in this matter I think it complicates the scheduler job even more, because the could be multiple advertisement competing for the baseband which could starve any ongoing connection.

WAI then.