How main harbour part (core contrib) require writing new one from from scratch? Which are?
2009/7/28 Przemyslaw Czerpak <[email protected]>: > On Tue, 28 Jul 2009, Lorenzo Fiorini wrote: >> > Fine, I also think it's reasonable but in such case we should fix value >> > stored in 2-nd parameter to follow documentation. >> > > 0 size of line with terminator >> > 0 - connection closed by foreign host >> > < 0 error >> It's ok for me. > > OK, so now the last problem with this function. > The documentation for hb_InetRecvLine() says: > "Incremental allocation and end-of-line checking are done in an > efficient way." > > The above is not true. This functions is implemented in the worst > possible way for performance. It calls recv() to extract single byte. > It means that the cost of switching between user and kernel space > is horrible huge and can kill the performance. I've seen how slow > it can be in some small programs written for pocket PC with WinCE. > The problem can be resolved by introducing internal buffer to > HB_SOCKET_STRUCT used by hb_inet*() functions and reading data in > bigger peaces. But it also means that we will have to update other > hb_inet*() functions to respect data in this buffer which can appear > after calling hb_InetRecvLine() or hb_InetRecvEndBlock() and I do > not know if I should invest time in cleaning this whole interface. > Maybe we should think about writing new one from scratch using > new hb_socket*() C functions? > How many people use current hb_inet*() functions and how important > is backward compatibility for you? > > best regards, > Przemek > _______________________________________________ > Harbour mailing list > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
