[gnet] Re: GNet library (2.0.5)



Hello,

thanks for replying. 

> GNet is thread-safe in the sense that there are locks around globals.
> However, there are not per-object locks. The async DNS functions use
> threads.
>
Thanks for clarifying. 

> Yes.  Callbacks can only be called from the event loop.  The even loop
> doesn't use signals.
>
Okay, great. 

> > - PLEASE: We need better error reporting.
> >
> >   One outstanding feature which we had long time under Unix and Linux
> >   (and still have on the command line) is fine-grained error reporting.
>
> Maybe - How do you want to do it?  Adding a gnet_errno is possible.
> Adding string support is harder because then GNet would need to support
> string translations.
>
I'd suggest to add it much like the other error reporting in glib: 

Functions that can fail take a return location for a GError as their last 
argument. For example:

gboolean g_file_get_contents (const gchar *filename, 
                       gchar      **contents,
                       gsize       *length,
                       GError     **error);

People who just want to go on reporting "could not..." to the user can pass 
NULL for the error. 

For callbacks lets simply pass an GError * as well. 

Well, things were easier here if you had introduced the use of a struct 
for each callback, using 

void (*GTcpSocketNewAsyncFunc)(struct GTcpSocketNewAscnyFuncParams *p)
with elements
  p->socket
  p->data
because this would allow to easily add 
  p->error  (as GError)
as well. 

(At least that is what I am doing for virtual functions in C++ since if you 
forget to change the argument list of one derived class' function it will 
no longer override. Using a parameter struct makes life easier if one adds 
improvements like error reporting.) 

So, now about the translation into a string. Well, this is actually the
easier 
part of both on POSIX. 

Just replace (I'm inventing something here): 

   retval = syscall( blah blah );
   if(retvak<0)  return(NULL);

with (assuming that error is the GError** passed to the function). 

   retval = syscall( blah blah );
   if(retval<0)
   {  gnet_set_syscall_error("operation","argument",error);  return(NULL); 
}

and using

  void gnet_set_syscall_error(const char *op,const char *arg,GError **error)
  {
    if(!error) return;
    int code = map_errno_to_code(errno);
    g_set_error(error,GNET_XYZ_ERROR,code,"failed to %s %s: %s",
      op, arg, g_strerror(errno));
  }

and map_errno_to_code() is some larger switch-case which maps errno values 
to an independent gnet-provided enum called GNetXYZError (to comply with 
glib naming conventions). [Something like g_file_error_from_errno()]

Okay, and "operation" and "argument" are easily inserted in above example: 
If syscall = open, then use "opening" and "<filename>"
If syscall = connect, use "connect to" and <hostname> or IP
If syscall = access, use "get access permissions of" and "<filename>"
and so on...
I've been doing system-level programming for years and it always works!

I hope I could explain what I mean; there are hopefully not any pitfalls 
(other than breaking the interface by introducing a GError argument to 
most of the functions / callbacks). 

> I think "Failed to connect" is fine for a user message.  Most users
> have no idea what the difference is between no route to host /
> connection timed out / etc.
>
I object here. Since programs I write are not for the "average stupid user" 
but for people who need to know more. And as for what I plan (some 
network distribution of calculations), connection refused, timeout and 
"no route to host" really make a difference and show you if the client 
died, the box went down or the network is broken. 

> Please use gnet gnetlibrary org in the future.  You'll probably get a
> faster response.
>
Okay; hope it does not require subscription prior to posting. 

Regards,
Wolfgang

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]