On Wednesday 10 January 2007 15:03, Randall Stewart wrote: > John: > > > > John Baldwin wrote: > > On Wednesday 10 January 2007 10:03, Randall Stewart wrote: > >> Robert/All: > >> > >> Ok, here is the deal... I have looked in a bit > >> closer at this.. > >> > >> Here is what is happening... > >> > >> When a cookie arrives, we get a "create lock" on > >> the socket this prevents the user on the same > >> socket from creating a assoc at the same exact time. > > > > Can't you do a model like this: > > > > lock(); > > if (need to create pcb) { > > unlock(); > > create_pcb(); // can sleep w/o holding lock > > lock(); > > if (someone else created the pcb) > > free(pcb_I_just_created); > > } > > unlock(); > > > The above is exactly what causes the race to occur.. > > There are several places where if we do that we end > up with two TCB's under certain collision cases.. which > can happen (I have a test app that gets it within a > few hours :-() Ah, you must have missed the part where it does: if (someone else created the pcb) { free(pcb I just created); use the other pcb; } :-P That is, explicitly handling the race. However: > I am NOT willing to sleep. the normal allocation of the PCB is done > with a WAIT type option.. I had not realized that hashinit() > did an allocation and could sleep.. thats the issue. In that case a hashinit_flags() is the way to go I guess. What happens if the hashinit fails, connection dropped? -- John BaldwinReceived on Wed Jan 10 2007 - 21:25:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC