Duda con threads

[ivancea96]

Gracias ahora funciona. La documentacion thread es algo mala en ningun lugar pone lo de ref()

Y una ultima pregunta 
Puedo hacer join del thread desde la función que llama el thread?
Lo necesito porque tengo un thread que hace los listen pero tiene que ser multiusuario por lo tanto el thread no puede tener nombre ni me puedo parar a esperar para que el thread se cierre si no que se tiene que terminar solo con join cuando el usuario se valla, esto ya lo detecto con los sockets.

http://www.cplusplus.com/reference/functional/ref/

Estoy seguro de que hay una forma mucho mejor de hacer lo que buscas. Si un thread se hace .join() a si mismo, no va a acabar ·_·

[amchacon]

Gracias ahora funciona. La documentacion thread es algo mala en ningun lugar pone lo de ref()

Y una ultima pregunta 
Puedo hacer join del thread desde la función que llama el thread?
Lo necesito porque tengo un thread que hace los listen pero tiene que ser multiusuario por lo tanto el thread no puede tener nombre ni me puedo parar a esperar para que el thread se cierre si no que se tiene que terminar solo con join cuando el usuario se valla, esto ya lo detecto con los sockets.

Vamos a ver, me lees cuando escribo o que?

La clase thread presupone que harás join en algún momento (al final del programa/funcion normalmente), si tu idea es dejar el hilo a tu aire tienes que usar detach()

Código (cpp) [Seleccionar] Expandir

thread t(hilo);
t.detach();

De todas formas, también puedes hacerlo con join(). Te haces un array de threads (al principio, vacios) y cuando sepas que un hilo se ha cerrado haces join (además de hacer join antes de cerrar el programa).

[patilanz]

Perdón no te había entendido lo de dejar al aire. Ahora ya todo esta perfecto.
Pero porque tengo que usar ref() cual es la diferencia en pasar lo por una función normal?
Gracias por tu paciencia

[ivancea96]

Puedes evadir el ref() si en vez de  de parámetros SOCKET& los pones como SOCKET*, y pasas mediante &variable.

[amchacon]

Perdón no te había entendido lo de dejar al aire. Ahora ya todo esta perfecto.
Pero porque tengo que usar ref() cual es la diferencia en pasar lo por una función normal?
Gracias por tu paciencia

A mí por lo menos no me compila.

Son detalles de la implementación de la librería (no es como una llamada a función, es más complejo...). En tal caso, usa ref para pasarlos parametros por referencia en la clase thread. Además el código queda bastante autoexplicativo (se ve que paramétros son por valor y cuales por referencia).

Puedes evadir el ref() si en vez de  de parámetros SOCKET& los pones como SOCKET*, y pasas mediante &variable.

Y cada vez que tengas que adceder, con el * y los -> de marras. Quita, quita.

Los punteros son del pasado ^^

[ivancea96]

Eso es para tu gusto e.e

[Eternal Idol]

Los punteros son del pasado ^^

Te recomiendo Java y C#.

[eferion]

Te recomiendo Java y C#.

Depende del uso... como necesites un algoritmo iterativo o recursivo con reservas de memoria en cada iteración... aunque luego las "liberes", te puedes encontrar con el caso de que el equipo se queda sin memoria en menos de un minuto... la razón es sencilla, al no tener tu control sobre el ciclo de vida sobre los objetos, éstos se quedan en estado latente esperando a ser eliminados por el recolector de basura... si tu aplicación no le da tiempo al recolector para trabajar, los objetos no se eliminan y la memoria se acumula hasta que te quedas sin nada.

Y no lo digo por decir, al menos en la versión 2.0 del framework de .Net es absurdamente sencillo... se puede hacer con bucles y clases de tipo string... no creo que las versiones posteriores hayan avanzado muchísimo en ese tema.

Moraleja: si el algoritmo o la aplicación hace un uso intensivo de memoria dinámica, .Net al menos ( y Java no creo que sea muy diferente ), no te sirven.

[Eternal Idol]

Depende del uso... como necesites un algoritmo iterativo o recursivo con reservas de memoria en cada iteración... aunque luego las "liberes", te puedes encontrar con el caso de que el equipo se queda sin memoria en menos de un minuto... la razón es sencilla, al no tener tu control sobre el ciclo de vida sobre los objetos, éstos se quedan en estado latente esperando a ser eliminados por el recolector de basura... si tu aplicación no le da tiempo al recolector para trabajar, los objetos no se eliminan y la memoria se acumula hasta que te quedas sin nada.

Y no lo digo por decir, al menos en la versión 2.0 del framework de .Net es absurdamente sencillo... se puede hacer con bucles y clases de tipo string... no creo que las versiones posteriores hayan avanzado muchísimo en ese tema.

Moraleja: si el algoritmo o la aplicación hace un uso intensivo de memoria dinámica, .Net al menos ( y Java no creo que sea muy diferente ), no te sirven.

¿Y cual es la diferencia al fin y al cabo si pretendes no usar punteros en C++ tampoco? Entiendo que leiste a lo que respondi ...

[eferion]

Si yo hago un bucle con strings sin usar punteros... en C++ tendré un uso bastante estable de la memoria.

En C# y Java usaré punteros sí o sí, solo que yo no voy a verlos como punteros porque esa parte la enmascara el framework... en este caso, el mismo ejemplo que con C++ resultará en un consumo absurdamente elevado de memoria hasta que el algoritmo termine y le de un respiro al recolector de basura para poder hacer su trabajo.