-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 05 January 2003 07:11 am, Dima K wrote: > The 2 major ones though are the fact that > ProcessRunningEvent_Server_tep doesn't really > guarantee the events are sent in order like it claims > to, the thread can easily pick an event and then > sleep while the next thread picks the next event and > sends it ahead of that 1st one.
OK, well wouldn't it be easiest to just lock the event queue and unlock it after the event is sent? That way all threads are blocked on the mutex until the event is sent. > The 2nd one is also in ProcessRunningEvent_Server_tep > and ProcessRunningEvent_Client_tep and has to do with > cancelling an event. This can be best demonstrated if > you try to send a message directly to a user behind a > firewall, the thread will block trying to connect to > the user.. if you cancel the event at this point, the > event instance will be deleted, and a cancel signal > sent to the thread, but the thread does not act on the > cancel signal since cancelation has been disabled.. > Once the connection fails, the now deleted event is > dereferenced by the thread and possibly even deleted > (again) in ProcessDoneEvent Well, isn't that what pthread_setcanceltype is for? So you can defer cancellation signals until it is able to receive them (pthread_tescancel)? Jon ______________________________________________________________ Jon Keating ICQ #16325723 [EMAIL PROTECTED] GPG ID: 0x2290A71F emostar on irc.openprojects.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+GGCtld1KayKQpx8RAmVzAJ9UDqG/ikRkKBz2LbgCpaW8eCbr6wCg023D IgWxoDIgMmUV1ntFtVGSOaw= =uQj/ -----END PGP SIGNATURE----- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Licq-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/licq-devel
