On Thu, 03 Dec 2009 00:42:47 -0500 Jeff Garzik <jeff@xxxxxxxxxx> wrote: > On 11/26/2009 09:39 PM, Pete Zaitcev wrote: > It seems to me you should > > a) leave current main-thread libevent code unchanged > > b) call event_base_new() for the new thread, passing that newly-created > event_base to replica thread events using event_base_set(). Isn't it exactly what I do right now? > event_reinit() seems more appropriate for forks than threads. tabled's > needs are simple -- you simply need to create an additional event_base > for the new thread. It wasn't obvious from the description and anyway, what's the harm? I thought it reopens some /dev/epoll or whatever may be necessary in the OS. > > + /* Statics are a silly way to pass arguments to threads, but oh well. */ > > + evbase = ev_base; > > + > > + scan_thread = g_thread_create(rep_thread_func, NULL, FALSE, &error); > > The second argument to g_thread_create() is a user-provided data > pointer, passed directly to the newly created thread. No need for a > static, AFAICS. Ignoring the comment for now, the problem is that evbase is needed in the "system context" of a thread, for things like passing it down to stor_open(). That's the main reason why it's static. Threads in Glib have something called "static private", which kinda-sorta works like what we need, but it's a pain. I guess I can try to use it... -- Pete -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
