On Fri, 25 Jan 2008, Alexander S.Kresin wrote: > >> The C level socket API is used in client part, because the RDD is > >>written on C. I don't see serious problem here, too, because I'm sure > >>that in the case of necessity appropriate separated parts can be easily > >>adopted. > PC> So how it will work with compressed socket when we add native > PC> support for stream compression? > Just borrowing appropriate piece of code. I hope that such important > additions won't come every month :).
Do you plan to make such updates each time when sth inside hbinet.c will be changed and test it for all supported by Harbour platforms? > PC> And what if Harbour socket will not have usable OS handle at all > PC> on some platforms? What if it will be necessary to hide some > PC> OS dependent differences? F.e. select() works a little bit different > PC> in MS-Windows then in *nixes. Even between *nixes there are some > PC> important differences in this function. Do you know these differences? > No. But I tested my code under both XP and Linux and didn't find any > difference. Maybe, I didn't dig deeply enough, though. f.e. detecting broken connection or time updating in timeval parameter. I do not know if your code needs it but for sure current hbinet.c code should be updated. > PC> If it will be portable then we will add it to hbinet.c. > PC> There is absolutely no reason to make hb_inetSocketFinalize > PC> public until we want to keep sockets internals 3-rd party > PC> code independent and easy expandable. > So, you confirm that hbinet.c can't be extended by 3-rd party > libraries and if someone need any changes or additions, he have to > modify the hbinet.c. And what if this changes aren't fully portable or > suitable for general use, but satisfy his specific needs ? Isn't this a > limitation, too ? Absolutely not. It's very important feature not limitation. 3-rd party code cannot change HB_SOCKET internals because it's not accessible for it so we do not have to worry that wrongly written code will break sth in our internals. But of course if you plan to make sth with low level OS socket what is not supported by us then you can. You only need one function: FHANDLE hb_inetGetOsHandle( PHB_ITEM pSocket ) and do what you want with the returned handle with hacking internal Harbour structures so you are not limited at all. > PC> The answer is very simple. .prg code should protect against low level > PC> errors like GPF. hb_parptrGC() validate if given pointer is a pointer > PC> to valid socket structure. hb_parptr() will also work but it will accept > PC> all possible pointer items not only these one which point to socket > PC> structure. Look at HWGUI. There is no validation at all so user can pass > PC> wrong pointers or handles to functions which will accept them and later > PC> GPF. Such code is unsafe. We should always try to write code as safe > PC> as possible. > You are right. Harbour's rtl is written for general use and this code > may be used in any kinds of applications, including those, where this > kind of safety is important - I mean, first of all, pieces of code, > which are intended for executing by some server. > In case of common desktop applications it is, IMO, isn't important. > Imagine, that programmer made a mistake and pass some bad word :) > instead of a handle to a function. Only his desktop application will > crash and after some time of hunting he will find that mistake. And, > probably, in case of GPF it will be more easy to identify the mistake > than if the GPF doesn't occur and he get some 'strange' application > behavior. That's why, for example, I don't worry about such things in > HwGUI - as any other GUI library, it is intended for desktop applications. > In the case of rdd for the db server it isn't an issue at all, because > the socket handle is hidden in workarea structure. The GPF is optimistic situation. In the worst case you can even lost important data. I remember an example when double call to fclose() caused that printer output was redirected to open DBF file. The code was working for years with Clipper and the bug was never exploited in such way but the problem begins to seldom happen after recompiling with xHarbour. > PC> As I said it's not necessary at all and so far you haven't answer > PC> why you need it. Again, please tell me which additional functionality > PC> is necessary for you and I'll add them to hbinet.c. > Ok. Below are the functions I've added: [...] > I know that this code isn't proper for general use, because it uses > one static rd_fds and, so this set of functions can't be used for > selecting concurrently from two sets of sockets. But it fully satisfies > my needs - at least now. I'll add general wrapper to select() function - it should be enough. > Other small change is that I've added 3'rd value of iMode to read and > send functions - to avoid the call of hb_selectReadSocket(), because I > check the socket before calling send() and receive() every time and > don't need an additional checking. The new API will respect it in the same or other way - I'll decide when I'll collect all functions. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
