J1 waiver 在2月底收到I797C,单目前USCIS的状态还是initial review,所以考虑是 否去做info pass。 如果要预约info pass,INFO PASS的网页上要求从如下4种appointment中选择: (1)Order from Immigration Court - If you were directed to us for processing based on an order from the Immigration Judge. You must bring all documents required in the post order instructions given to you by the court. (2)Case Processing Appointment - If you received a notice to go to your local office for further case processing. (3)EAD inquiry appointment - If your I-765 employment authorization application has been pending for more than 90 days. (4)Case Services follow-up appointment - If it has been over 45 days since you contacted NCSC and have not received a response to your inquiry. You must bring the Service Request ID Number related to your inquiry to the appointment. 前3种似乎都与J1 WAIVER无关。第4种好像要求先打电话做Service Request,然后还要 再等45天才可以做info pass。真的是这样的吗?大家是怎么做info pass的?
the write can be buffered, just like a normal log file, you don't have to flush for every write. you don't return response to a request till that record is flushed. latency will be higher but throughput stay the same.
You can't buffered write, because it's not just write, you also need to update counter according to his design. And if you buffer update too, you risk selling too many.
【在 G********f 的大作中提到】 : the write can be buffered, just like a normal log file, you don't have to : flush for every write. you don't return response to a request till that : record is flushed. latency will be higher but throughput stay the same.
G*f
71 楼
a request come in, u update the counter, then write a log to buffer, then deal with next request. after N request, u flush the buffer, then for each log entry in the buffer, send a response to the corresponding request. so essentially u delayed the response till the log is flushed. it is kind of a asynchronous solution where u trade latency for throughput.
【在 g*****g 的大作中提到】 : You can't buffered write, because it's not just write, you also need to : update : counter according to his design. And if you buffer update too, you risk : selling too many.
at best you avoid sequential write by introducing morw writes, its on upper bound already, hardly an improvement.
a
【在 G********f 的大作中提到】 : a request come in, u update the counter, then write a log to buffer, then : deal with next request. after N request, u flush the buffer, then for each : log entry in the buffer, send a response to the corresponding request. so : essentially u delayed the response till the log is flushed. it is kind of a : asynchronous solution where u trade latency for throughput.