还是继续上一个话题,线程池的关系...还没弄懂..

kissjetg 2014-04-22 01:30:02
由于上一次很多热心的网友提供的多种方案.个人也去看了一个重量级的线程池OmniThreadLibrary,发现他的任务是我所需要的功能.但是由于教程比较少..自己只作为一个收集存放起来.待日后再详细研究.感谢版主.....

但是目前所需要的是一个快速能够开发的线程池..在不断的纠结中..只能重新找过一套线程.但是那一套线程池只能在DELPHI7下编译通过..由于个人技术的原因.未能使其支持XE5.所以特发此贴.望有心人能够将其改为支持XE以上版的线程池以造福我此等的菜鸟....分数可以增加.....下面赋上我在下载的地址.
http://www.2ccc.com/article.asp?articleid=3592#

再赋上我编译时出现的错误.

这是DELPHI7 下的编译程序....
...全文
213 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
kissjetg 2014-04-28
  • 打赏
  • 举报
回复
引用 10 楼 Avan_Lau 的回复:
[quote=引用 9 楼 kissjetg 的回复:] 首先真感谢版主的热情..很少能见到这样的人了...但是按照版主的说明.我如果真需要用到线程池的技术.是不是只能通过自己的思路写一款.或者有成熟的产品可以替代?更或者说像OmniThreadLibrary大级别的线程池..只是网上教程少....自己也手动写了几个方式.确实不错...而且也能运行.只是和我要求的线程池模型有点出入.希望能指教一下..免走很多弯路
谢谢。看你开帖和回帖时间,基本是在凌晨1点左右。能潜心、专注研究技术问题,这种精神让我很钦佩。自问很少做到。 如果需要进一步帮助,可以跟我QQ联系(网站私信给我)。这里有三个建议: 1、参考OminiThreadLibrary文档。这个开源项目,有完整的帮助,并且有匹配的UML图描述各种类之间的关系,有助于整体把握; 2、如果要自行构建自己的线程池模型,建议也尝试用类结构图和时序图描述:一来可用于交流设计思想;二来有助于后续维护; 3、如果可以,参考你现在研究的线程池,根据其设计方式,再实现;[/quote]
引用 10 楼 Avan_Lau 的回复:
[quote=引用 9 楼 kissjetg 的回复:] 首先真感谢版主的热情..很少能见到这样的人了...但是按照版主的说明.我如果真需要用到线程池的技术.是不是只能通过自己的思路写一款.或者有成熟的产品可以替代?更或者说像OmniThreadLibrary大级别的线程池..只是网上教程少....自己也手动写了几个方式.确实不错...而且也能运行.只是和我要求的线程池模型有点出入.希望能指教一下..免走很多弯路
谢谢。看你开帖和回帖时间,基本是在凌晨1点左右。能潜心、专注研究技术问题,这种精神让我很钦佩。自问很少做到。 如果需要进一步帮助,可以跟我QQ联系(网站私信给我)。这里有三个建议: 1、参考OminiThreadLibrary文档。这个开源项目,有完整的帮助,并且有匹配的UML图描述各种类之间的关系,有助于整体把握; 2、如果要自行构建自己的线程池模型,建议也尝试用类结构图和时序图描述:一来可用于交流设计思想;二来有助于后续维护; 3、如果可以,参考你现在研究的线程池,根据其设计方式,再实现;[/quote] 谢谢版主鼓励,这些天,天天在看线程池,以前也曾经写过一些简易的线程池,但感觉运行久了不稳定.,这一次决心全力找一些好的线程池一边学习一边打造属于自己的线程池,苦于自身的悟性缺乏.只能希望求助于别人的指导以开拓自己的视野..而UML更是头一回听见,希望能得到版主的帮助..感谢不已,已向您发个私信,希望能要个QQ加个好友..
kissjetg 2014-04-28
  • 打赏
  • 举报
回复
兜兜转转,找了OmniThreadLibrary-3.03b完整的一些资料,一始一步一步的实践里面的示例.然后写个日志...........谢谢版主..结贴先..
金卯刀 2014-04-27
  • 打赏
  • 举报
回复
引用 9 楼 kissjetg 的回复:
首先真感谢版主的热情..很少能见到这样的人了...但是按照版主的说明.我如果真需要用到线程池的技术.是不是只能通过自己的思路写一款.或者有成熟的产品可以替代?更或者说像OmniThreadLibrary大级别的线程池..只是网上教程少....自己也手动写了几个方式.确实不错...而且也能运行.只是和我要求的线程池模型有点出入.希望能指教一下..免走很多弯路
谢谢。看你开帖和回帖时间,基本是在凌晨1点左右。能潜心、专注研究技术问题,这种精神让我很钦佩。自问很少做到。 如果需要进一步帮助,可以跟我QQ联系(网站私信给我)。这里有三个建议: 1、参考OminiThreadLibrary文档。这个开源项目,有完整的帮助,并且有匹配的UML图描述各种类之间的关系,有助于整体把握; 2、如果要自行构建自己的线程池模型,建议也尝试用类结构图和时序图描述:一来可用于交流设计思想;二来有助于后续维护; 3、如果可以,参考你现在研究的线程池,根据其设计方式,再实现;
kissjetg 2014-04-27
  • 打赏
  • 举报
回复
首先真感谢版主的热情..很少能见到这样的人了...但是按照版主的说明.我如果真需要用到线程池的技术.是不是只能通过自己的思路写一款.或者有成熟的产品可以替代?更或者说像OmniThreadLibrary大级别的线程池..只是网上教程少....自己也手动写了几个方式.确实不错...而且也能运行.只是和我要求的线程池模型有点出入.希望能指教一下..免走很多弯路
金卯刀 2014-04-26
  • 打赏
  • 举报
回复
建议你还是放弃这个转换,因为在XE下安装Indy会与DataSnap产生冲突。参考Indy官方说明 3) In D/CB/RAD 2009-XE, Embarcadero's DataSnap framework is compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render DataSnap unusable, as it will not be able to load the Indy packages anymore, and DataSnap cannot be recompiled by end users. If you need to use DataSnap, then you will need to maintain the original Indy 10 packages for use in DataSnap projects. You can use a separate installation of Indy 10 for non-DataSnap projects. This was addressed by Embarcadero in D/CB/RAD XE2 so Indy 10 upgrades and DataSnap can co-exist. 4) In D/CB/RAD XE2 up to, and including, Update 3, an erroneous dependancy on Indy has been identified in Embarcadero's dclnet160.bpl package. Installing a new version of Indy will cause this package to fail to load correctly in the IDE, preventing all contained components (such as THTTPRIO, TXMLDocument, TWeb*Dispatcher, T*Producer, TTcp*, TUdp*), as well as Wizards and Property Editors for them, from appearing at design-time. The run-time components can still be instantiated dynamically in your run-time code, though! Embarcadero is aware of the problem, and has already fixed the problem for XE3. Removing the dependancy causes an interface change in dclnet.dcp, and Embarcadero does not normally release interface changes in product Updates, however the change is internal to Embarcadero's code only and should not effect end users, so Embarcadero is hopeful that the fix can be included in a near-future XE2 Update. 5) in D/CB/RAD XE2 Update 4, the DCLIPINDYIMPL160.BPL package has a link to Indy's IdHeaderCoderUTF unit, which does not exist in Indy anymore and was replaced with the IdHeaderCoderIndy unit. Installing a newer version of Indy will cause a linker error in this package. According to Embarcadero, this package is the only design-time package that should require rebuilding after upgrading Indy with any kind of interface changes or unit list cha-nges. The source for this package is provided in XE2, users can find it under $(BDS)\source\indy\implementation. 6) in D/CB/RAD XE3, Embarcadero changed the signature of the TIdUDPServer OnUDPRead event in the bundled copy of Indy 10. This was done in an attempt to address a slew of related QC bug reports (#88816, #89298, #89662, #92067, #93672, #94969, #97943, #99863, #103088, #104825) so the Delphi compiler would generate RTTI that allows the IDE to produce an event handler that is compatible with both Delphi and C++Builder without errors and without requiring additional RTL/compiler changes (which are actually needed to solve the root cause of the original errors). Specifically, the AData parameter of the OnUDPRead event was changed from a Dynamic Array to an Open Array. Consequently, the parameter signature is now different, which means that pre-existing user code that uses the OnUDPRead event in earlier D/CB/RAD versions will no longer work correctly without being updated accordingly. This change was NOT approved by the Indy development team, and Embarcadero did NOT apply their change to other areas of Indy that are affected by the same issue, such as the TIdTelnet OnDataAvailable and IdIPMCastClient OnIPMCastRead events. To maintain a single codebase, these changes have been merged into subsequent SVN releases of Indy 10. There have been some reports that when compiling Indy for XE3, the compiler may complain about missing *.otares files. This is caused by a {$R *.otares} statement in the .dpk files. The files that are checked in to SVN do not contain this statement, but apparently the compiler may decide to insert it on its own. If this happens, just remove the statement and recompile again. Indy does not use *.otares files. They are generated by the IDE when it encounters unknown resources while upgrading a project from an older IDE version. http://www.indyproject.org/Sockets/Docs/Indy10Installation.EN.aspx
kissjetg 2014-04-24
  • 打赏
  • 举报
回复
引用 5 楼 Avan_Lau 的回复:
[quote=引用 4 楼 kissjetg 的回复:] [quote=引用 3 楼 Avan_Lau 的回复:] 晚上回去帮你看看,公司这边没有XE的环境
版主现在使用的还是传统DELPHI7吗?[/quote] 主要用D2009。那个源码,在XE下,装上Indy之后,稍微改改就好了,demo可以运行...没有多大的错误[/quote] 自己顶一个...
金卯刀 2014-04-23
  • 打赏
  • 举报
回复
引用 4 楼 kissjetg 的回复:
[quote=引用 3 楼 Avan_Lau 的回复:] 晚上回去帮你看看,公司这边没有XE的环境
版主现在使用的还是传统DELPHI7吗?[/quote] 主要用D2009。那个源码,在XE下,装上Indy之后,稍微改改就好了,demo可以运行...没有多大的错误
kissjetg 2014-04-23
  • 打赏
  • 举报
回复
引用 5 楼 Avan_Lau 的回复:
[quote=引用 4 楼 kissjetg 的回复:] [quote=引用 3 楼 Avan_Lau 的回复:] 晚上回去帮你看看,公司这边没有XE的环境
版主现在使用的还是传统DELPHI7吗?[/quote] 主要用D2009。那个源码,在XE下,装上Indy之后,稍微改改就好了,demo可以运行...没有多大的错误[/quote] 啊~那请问能不能把改完的发代码发出来看看啊??或者直接打包给个下载地址.可以吧一.
金卯刀 2014-04-22
  • 打赏
  • 举报
回复
你的预编译条件加上Delphi,可以避免此错误;或者删除这几行; 另外,在d2010以上,单元命名空间重新整过,原有的单元名称需改为类似 system.xxxx。
kissjetg 2014-04-22
  • 打赏
  • 举报
回复
引用 3 楼 Avan_Lau 的回复:
晚上回去帮你看看,公司这边没有XE的环境
版主现在使用的还是传统DELPHI7吗?
金卯刀 2014-04-22
  • 打赏
  • 举报
回复
晚上回去帮你看看,公司这边没有XE的环境
kissjetg 2014-04-22
  • 打赏
  • 举报
回复
当中那几行删除之后出现了更多的错误.整理了好长时间也没整理出个结果....悲催..

1,593

社区成员

发帖
与我相关
我的任务
社区描述
Delphi 网络通信/分布式开发
社区管理员
  • 网络通信/分布式开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧